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Why nor rake rhe shorresr and fasresr roure 
toward sysrem design solurions? To define 
and model a large, complex sysrem, you 
need o modeling tool rhar con address rhe 
sysrem's rotol archirecrure. 

f j) PAWS/GPSM™ is on easy-to-use high 
fk producrivity modeling and simularion 
jBt tool rhar lers you evaluate alrernarive 
archirecrures while focusing on performance. 
Ir provides a srare-of-rhe-ait environmenr for 
developing accurate and reliable producr 
definirions. 

|| PAWS provides high level primitives 
closely resembling rhe user's inruirion. 
PAWS models rhe behavior of a totol 
sysrem implemented in diverse technologies 
including software, hardware, and firmware. 

IRA 


II. GPSM, rhe graphical interface to 
1^ PAWS, helps you quickly and easily 
transfer your ideas into pictures. GPSM 
helps you visualize multiple data and control 
flows through several components and 
incrementally synthesize models of a total 
sysrem. 

f 4) PAWS/GPSM is flexible. It lets you refine 
your model os your system design 
JHb evolves so you can eliminate potential 
problems os early as possible in the product 
design cycle. 

Call (512) 474-4526 to receive information 
on PAWS/GPSM. And get on the PAW5 
expressway to system design solutions. 
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Computer—communications network 
simulation-quick results, no programming 


See your proposed network perform under various workloads 

NETWORK II.5 now gives you easy-to-understand simulation 
results quickly—no programming 


W ith NETWORK II.5 you 
enter your computer — 
communications network descrip¬ 
tion. 

Simulation follows immediately 
-no programming delays. 

Easy-to-understand results 

Your reports show utilization, 
queues, execution times, response 
times and conflicts. 

Graphical reports show hardware 
layout, software data flow, and 
device utilization. 

Seeing graphical results 
increases everyone’s understanding 
of your proposed network and 
builds confidence in the analysis. 

Your system simulated 

You can analyze any computer 
—communications system including 
local area networks. 

You can simulate some portions 
of the system at a detailed level 
and others at a coarser level. 

Widely used protocols are built-in 
-you just make a choice. 


Free trial and training offer 

The free trial contains everything 
you need to try NETWORK II.5® 
on your computer. 

You may develop your own net¬ 
work or modify one of ours. 

Try the NETWORK II.5 ap¬ 
proach, the quality and timeliness of 
our support, the accuracy of our 
documentation and the facilities for 
error-checking— everything you need 
for a successful project. 

No cost, no obligation. 

Act now-free training offer 

For a limited time we also 
include free training. Typical ap¬ 
plications are demonstrated. 

Call today to avoid disappoint¬ 
ment-class size is limited. 

For immediate information 

Call Paul Gorman at (619) 
457-9681. In the UK, call Steve 
Wombell on (01) 940-3606. 

The quickest, easiest way for 
you to evaluate network alternatives 
is with NETWORK D.5. 


With NETWORK U.S you get 
results sooner and they are better 
understood. 


Rush information on the 
NETWORK II.5 free trial and 
training offer 

Free trial-learn the reasons for the 
broad and growing popularity of NET¬ 
WORK 11.5 — no cost, no obligation. 

Limited offer-return the coupon today 
and we will include one free course enroll¬ 
ment worth $850. 







Return to: 

CACI 

3344 North Torrey Pines Court 
La Jolla, California 92037 

Or, better yet, call Paul Gorman at 
(619) 457-9681 
In the UK 

CACI 

26 The Quadrant 

Richmond, Surrey, England TW9 1DL 

Call Steve Wombell on (01) 940-3606 


NETWORK II.5 is a registered trademark and service 
mark of CACI, INC.-FEDERAL 
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An algorithm animation environment like Balsa-II provides an “exploratorium” for investigating the dynamic 
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• Specific datagram protocols studied. 
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Factory Communications: 

• Communications protocols and standards in manufacturing: 
The key forces prompting their development. 
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President’s MESSAGE 



Edward A. Parrish, Jr. 


Growing CS Press to 

It should come as no surprise to any 
member that publishing is one of the 
Computer Society’s major services. In 
addition to its periodicals, the society 
publishes numerous aperiodicals—such 
as conference proceedings, tutorials, 
and books of reprints—under the 
auspices of the Computer Society Press. 
Recognizing the growing importance of 
CS Press activities, the 1987 Long-Range 
Planning Committee recommended that 
a task force investigate the full potential 
for future expansion. 

The task force was established in July 
1987 and gave its report at the March 4, 
1988, Board of Governors’ meeting. Its 
principal recommendation, and the one 
I want to discuss here, concerns a 
change in the society’s organizational 
structure. 

At present, the vice president for 
publications heads the Publications 
Board, which oversees all publication- 
related activities, including CS Press. 

Since we now have six magazines and 
three transactions, with the new IEEE 
Transactions on Knowledge and Data 
Engineering scheduled to begin publica¬ 
tion in 1989, there is simply too much 
activity across a broad spectrum for one 
vice president to manage. For some 
time, the society’s leaders have agreed 
that CS Press had reached the point of 
requiring more attention than the Publi¬ 
cations Board could give it. 

After reviewing the ongoing activities 
of CS Press, the task force recom¬ 
mended creating a vice presidential 
position to head a new CS Press Board. 

It further proposed that this new board 
consist of the editor-in-chief of CS 
Press and the chairs of the Press Opera¬ 
tions Committee, the Planning Com¬ 
mittee, the New Products Committee, 
the Sales and Promotions Committee, 
and other members to be appointed by 
the vice president. 

At the Board of Governors’ meeting, 
the recommendations were presented in 
the form of a motion which amended 
the society’s bylaws. The motion passed, 
and the proposed amendment is now 
before the membership for comment. 

(See Computer Society News in this 
issue for complete text.) After consider¬ 
ation of any comments received, the 
board will hold a second vote on the 
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motion at its next meeting, to be held 
June 17 during the 25th Design Automa¬ 
tion Conference in Anaheim, California. 

Assuming the motion passes for the 
second time and the new structure 
becomes codified within the bylaws, I 
intend to appoint a new vice president 
for CS Press immediately. The new CS 
Press Board will then be appointed and 
charged with carrying out a number of 
actions designed to enhance both the 
products and the kinds of activities per¬ 
formed under the aegis of the CS Press. 

I expect that the membership will see 
the dividends resulting from the reor¬ 
ganization almost immediately, in the 
form of increased offerings. 

Other changes are being contem¬ 
plated, but are farther from implemen¬ 
tation. For example, we anticipate 
increased interaction between CS Press 
and other entities within and without 
the society. A particularly appropriate 
target is the rapidly growing standards 
area. Draft standards would be pub¬ 
lished by CS Press in support of our 
very active standards participants. 
Another target with high potential is the 
educational arena, in which the Educa¬ 
tional Activities Board plays an impor¬ 
tant role, developing “standards” like 
model curricula. Another is the techni¬ 
cal committees, which are moving 
toward more formal communications 
with their members by way of periodic 
publications of their own. 

We are in the process of hiring an 
assistant director of CS Press, thus fill¬ 
ing a new staff position recently author¬ 
ized by the Board of Governors. This 
new position will be critical in helping 
CS Press carry out its expanding role 
within the society’s larger aim of 
providing timely and appropriate ser¬ 
vices to the membership. 

In closing, I would like to thank pub¬ 
licly the chair of the task force, Jim 
Aylor (vice president for publications), 
and its members Tom Cain, Chip Hat¬ 
field, Chuck Silio, and Chip Stockton. 
They devoted considerable time and 
energy in arriving at the report. I hope 
to move forward rapidly in implement¬ 
ing their recommendations. 

Edward A. Parrish, Jr. 

Computer Society President 
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Challenging 
The Speed of 
Light 


Supercomputer Systems, Inc. designs 
and develops advanced parallel super¬ 
computers. We are expanding our 
hardware and software development 
teams. An exciting career opportu¬ 
nity awaits those who share our vi¬ 
sion of the future. With demon¬ 
strated ability in any of the following 
areas, you can join a group of expe¬ 
rienced designers creating a super 
fast computer. 

HARDWARE 

DEVELOPMENT 

Logic and system design, high perfor¬ 
mance processors, memory, I/O, 
peripheral and diagnostic subsystems. 

SOFTWARE 

DEVELOPMENT 

Supercomputer software, UNIX™ 
operating system, drivers and utili¬ 
ties, advanced compilation technol- 
ogy, peripheral, diagnostic, and oper¬ 
ator support subsystems. 

APPLICATION 

DEVELOPMENT 

Parallel computing, numerical al¬ 
gorithms, graphics, vector and paral¬ 
lel code optimizations, mathematical 
libraries, and large-scale scientific and 
engineering applications. 

BS/MS in an appropriate discipline 
with five or more years of related 
experience required. SSI offers a 
competitive salary and a comprehen¬ 
sive benefit package. For confidential 
consideration, please submit your re¬ 
sume to: Personnel, Supercomputer 
Systems, Inc., 1414 W. Hamilton Avenue, 
Eau Claire, Wl 54701 

AN EQUAL OPPORTUNITY 
EMPLOYER 
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Technically substantive reviews 


One of my objectives when I assumed 
the duties of editor-in-chief was to get a 
substantially larger number of Com¬ 
puter’s readers involved in the submis¬ 
sion of manuscripts and in the 
refereeing process. I am pleased to say 
that — although I would still like to 
double both the submission rate and the 
pool of referees — this goal has, to a 
large extent, been achieved. 

During 1987, over 940 people gave 
freely of their time and technical exper¬ 
tise to write and referee manuscripts 
for consideration for publication in 
Computer. In addition, the members 
of Computer’s Editorial Board and the 
department editors have given an 
extraordinary amount of their time to 
maintaining the high standards I have 
set for the magazine. 

Those of you who have written tech¬ 
nical papers know from experience how 
much time and effort it takes to develop 
a manuscript that is both readable and 
technically relevant. You also know 
how important a good, detailed review 
is in improving its overall quality. 

I do not take the refereeing of 
manuscripts lightly. Typically, a manu¬ 
script submitted to Computer is sent for 
review to six people who are actively 
working in the topic area. The guest 
editors and I expect referees to make 
constructive, detailed comments that 
will help the author(s) to 

(1) correct errors and misconceptions; 

(2) state appropriate, accurate, and 
relevant conjectures and results; 

(3) employ better definitions, dia¬ 
grams, tables, graphs, and examples; 

(4) use a minimum of contemporary, 
relevant, and essential references; 

(5) make the article technically con¬ 
sistent and complete; and 

(6) organize the material to help the 
reader understand the issues presented. 

If a referee does not cover at least 
several of these issues, we usually reject 
his report. We then submit the manu¬ 
script to additional reviewers, just as we 
do if the referees give conflicting views. 
We expect a strong consensus before 
accepting a manuscript. 

Doing this type of detailed, insightful 
referee’s report takes time and effort, 
but the payoff — publication of techni¬ 



Bruce D. Shriver 


cally substantive, timely articles — 
benefits Computer’s entire readership. 
Thus, having technically responsible 
referees is critically important to the 
magazine’s livelihood. 

Completing the review can be a 
lengthy process. Some manuscripts have 
been in this process for over a year 
(counting time for author revisions, 
which are also placed in review), but the 
majority of manuscripts complete the 
process in four to six months. This is an 
enviable record considering the stan¬ 
dards employed and number of people 
involved. 

If you would like to be a part of this 
worthwhile endeavor, please circle num¬ 
ber 191 on the Reader Service Card or 
send me your name, address (both phys¬ 
ical and electronic), phone number, 
subject areas (according to the Comput¬ 
ing Reviews classification system), and 
number of articles per year you can 
review. 

I acknowledge and thank the referees 
(listed at right and on the following 
pages), my Editorial Board, and my 
department editors for their efforts on 
Computer’s behalf. 

Bruce D. Shriver 

Editor-in-chief 
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Computer referees, 1987 

Mokhtar Abeolaze, University of Illinois, Urbana 

Miron Abramovici, Bell Telephone Laboratories 

Marc Abrams, IBM Zurich Laboratory, Switzerland 

Evans J. Adams, East Tennessee State University 

George B. Adams, NASA Ames Research Center 

J. Mack Adams, National Science Foundation 

Gabriela Adler, IBM Corporation, Los Angeles 

Ramesh Agarwal, IBM T.J. Watson Research Center 

Sudhir Aggarwal, Bell Communications Research 

Dharma P. Agrawal, North Carolina State University 

Vinod K. Agrawal, McGill University, Canada 

Raymond Ahlberg, United States Department of Commerce 

Hideo Aiso, Keio University, Japan 

Marco Ajmone-Marsan, Politecnico Di Torino, Italy 

John C. Akbari, JCA & Associates 

Winser Alexander, North Carolina State University 

Cecil O. Alford, Georgia Institute of Technology 

Stephen J. Allan, Utah State University 

Frances Allen, IBM T.J. Watson Research Center 

Robert B. Allen, Bell Communication Research 

Keith R. Allen, Clemson University 

Robert H. Allen, Central Remedial Clinic, Ireland 

Dennis Allison, Stanford University 

Luis B. Almeida, INESC, Portugal 

Guy T. Aimes, Rice University 

Joshua Alspector, Bellcore 

Hideharu Amano, Keio University, Japan 

George J. Ammon, RCA Advanced Technology Laboratories 

Charles W. Anderson, GTE Laboratories, Inc. 

Dana Anderson, University of Colorado 

Roger E. Anderson, Lawrence Livermore National Laboratory 

James Anderson, Brown University 

J. Wayne Anderson, Los Alamos Scientific Laboratories 

William Anderson, Xerox Corporation, Wilson Center for Technolgy 

Richard Andrew, Cranfield Institute of Technology, England 

Suleyman Anil, ITT, Italy 

Guillermo F. Arango, University of California, Irvine 

Bruce W. Arden, University of Rochester 

Mark A. Ardis, CMU, Software Engineering Institute 

Godefridus J. Arink, Philips Medical Systems, The Netherlands 

Ray Arrathoon, Wayne State University 

James D. Arthur, Virginia Polytechnic Institute 

Sigridur Augusta Asgrimsdottir, Iceland 

David Aspinall, University of Manchester, England 

R.A. Athale, BDM Corporation 

David Athersych, St. Lawrence College, Canada 

Robert W. Atherton, In-Motion Technology 

Joshua S. Auerbach, IBM T.J. Watson Research Center 

Marc A. Auslander, IBM T.J. Watson Research Center 

James Austin, University of York, England 

Takanobu Baba, Utsunomiya University, Japan 

Jean-Loup Baer, University of Washington 

Denis Baggi, Mettler Instruments AG, Switzerland 

Nader Bagherzadeh, University of Texas, Austin 

Ted P. Baker, Florida State University 

James Baldo, Institute of Defense Analysis 

Dana H. Ballard, University of Rochester 

Prithvira Banerjee, University of Illinois, Urbana 

Mario Barbacci, Carnegie Mellon University 

Roberto Barbuti, Universita di Pisa, Italy 

Paul Bardell, IBM Poughkeepsie 

Robert J. Baron, University of Iowa 

Harry G. Barrow, Schlumberger Palo Alto Research 

Andrew G. Barto, University of Massachusetts 

Victor Basili, University of Maryland 

M.A. Bassiouni, University of Central Florida 

Farokh B. Bastani, University of Houston 

Ted E. Batchman, University of Virginia 

Wulf Bauerfeld, Deutsches Forschungsnetz, West Germany 

Eric Baum, JPL, California Institute of Technology 


Paul R. Beaudet, Westinghouse 
Joseph D. Becker, Xerox Corporation 
Lee A. Becker, Worcester Polytechnic Institute 
Richard K. Belew, University of California, San Diego 
Fevzi Belli, Hochschule Bremerhaven, West Germany 
Mordechai Ben-Ari, Israel Institute of Technology, Israel 
Donald Bennett, Unisys Corporation 
Helmut Berg, Honeywell, Inc. 

Aviv Bergman, SRI International 
P. Bruce Berra, Syracuse University 
Dan Berry, Technion, Israel 
Edward H. Bersoff, BTG, Inc. 

P.J. Besl, General Motors Research 
Oliver E. Bessette, RCA 

Philipp W. Besslich, University of Bremen, West Germany 

Bir Bhanu, Honeywell Systems and Research Center 

Bhargab B. Bhattacharya, Indian Statistical Institute, India 

Laxmi N. Bhuyan, University of Southwestern Louisiana 

James M. Bieman, Iowa State University 

Frank Biemans, Philips Laboratories 

Alexandras Biliris, Boston University 

Abbas Birjandi, Northeastern University 

Yitzhak Birk, IBM Almaden Research Center 

Andrew Black, Digital Equipment Corporation 

Michael Blackburn, Naval Ocean System Center 

Rodger Blair, Carnegie Mellon University 

Wolf-Ekkehard Blanz, IBM Almaden Research Center 

Meera M. Blattner, Lawrence Livermore National Laboratory 

Bruce I. Blum, Johns Hopkins University 

Shahid H. Bokhari, University of Engineering and Technology, Pakistan 

Ruud M. Bolle, IBM T.J. Watson Research Center 

Sandro Bologna, ENEA Centro Ricerche Energia Casaccia, Italy 

Axel P.M.C. Bonaert, Sait, Belgium 

Grady Booch, Rational Machines 

Lyle J. Borg-Graham, MIT, Whitaker College 

Peter Borgwardt, University of Minnesota 

Paul L. Borrill, Spectra-Teic, UK Limited, England 

B.A. Bowen, Carleton University, Canada 

John B. Bowen, Hughes Aircraft Company 

Salvador Bracho, University of Cantabria, Spain 

Linda Brackenbury, University of Manchester, England 

William C. Brantley, IBM T.J. Watson Research Center 

Malcolm H. Brantz, University of Connecticut Health Center 

Howard Brauer, IBM Palo Alto Scientific Center 

John Breiland, Bell Telephone Laboratories 

Melvin A. Breuer, University of Southern California 

Ruven Brooks, Schlumberger-Doll Research 

Alan V. Brown, IBM Corporation 

Michael C. Browne, Carnegie Mellon University 

Tom Brumett, NCR Corporation 

Giorgio Bruno, Politecnico di Torino, Italy 

Glenn R. Bruns, MCC 

William Bryan, CTEC, Inc. 

Fletcher J. Buckley, RCA 

Richard E. Buehrer, ETH-Zentrum, Switzerland 

Daniel Bullock, Boston University 

Richard B. Bunt, University of Saskatchewan, Canada 

Mike Burke, IBM T.J. Watson Research Center 

Walter H. Burkhardt, Universitet Stuttgart, West Germany 

Luanne Burns, IBM T.J. Watson Research Center 

Jon Butler, Naval Post Graduate School 

Steven Butner, University of California, Santa Barbara 

Marty Cagan, Hewlett-Packard Laboratories 

Bob Caldwell, IBM Corporation 

Alberto R. Calero, Hewlett-Packard, Spain 

Andrea Califano, IBM T.J. Watson Research Center 

Robert Campbell, IBM T.J. Watson Research Center 

Paolo Camurati, Politechnico di Torino, Italy 

Victor Canivell, Hewlett-Packard, Switzerland 

Michael Caplinger, Bell Communication Research 

Peter C. Capon, University of Manchester, England 

David A. Carlson, IDA Supercomputing Research Center 

William W. Carlson, Purdue University 

Paolo Carnevali, IBM Corporation, Italy 
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Christian Carrez, Conservatoire National d’ Arts et Metiers, France 

Tony M. Carter, University of Utah 

David Casasent, Carnegie Mellon University 

Richard P. Case, IBM Corporation 

Yves Caseau, Laboratories de Maucovssis, France 

Massimo Casilli, Italy 

Patrick F. Castelaz, Hughes Aircraft Company 

John Cater, Digital Signal Corporation 

H.J. Caulfield, University of Alabama, Huntsville 

John R. Cerva, Mitre Corporation 

N.B. Chakraborti, Indian Institute of Technology, India 

Donald D. Chamberlin, IBM Almaden Research Center 

William S.C. Chang, University of California, San Diego 

A.B. Cheese, University of Nottingham, England 

Rama Chelleppe, University of Southern California 

Chuen-Liang Chen, National Taiwan University, Taiwan 

Marina C. Chen, Yale University 

Peter P.S. Chen, Louisiana State University 

Su-shing Chen, University of North Carolina 

Wu-Tung Cheng, AT&T Technologies Engineering Research Center 

Ram Chillarege, IBM T.J. Watson Research Center 

George Chiu, IBM T.J. Watson Research Center 

Barbara A. Christoph, SR A Corporation 

Wesley W. Chu, University of California, Los Angeles 

Henry Y. Chuang, University of Pittsburgh 

Israel Cidon, IBM T.J. Watson Research Center 

Luigi Ciminiera, Politechnico di Torino, Italy 

Linore Cleveland, IBM T.J. Watson Research Center 

Allan R. Clyde, A.R. Clyde Associates 

Robert Cogne, France 

Michael A. Cohen, Boston University 

Serge Henri Collin, Propriete Industrielle, Belgium 

Dean R. Collins, Texas Instruments 

Robert P. Colwell, Multiflow Computer 

Jeff Conklin, MCC 

Mickey Conners, City College of New York 

Peter R. Conwell, Unisys Corporation 

Robert P. Cook, University of Virginia 

Lawrence A. Coon, Rochester Institute of Technology 

Tom Corbi, IBM T.J. Watson Research Center 

Merrill A. Cornish, Texas Instruments 

Joelle Coutaz, Laboratoire de Genie Informatique, France 

John Crow, IBM T.J. Watson Research Center 

James L. Crowley, University of Grenoble, France 

Claude A. Cruz, Plexus Systems 

K. Wayne Current, University of California, Davis 

Bill Curtis, MCC Software Technology Program 

Ron Cytron, IBM T.J. Watson Research Center 

Edward Denning Dahl, Lawrence Livermore National Laboratory 
Timothy Daly, IBM T.J. Watson Research Center 
Werner Damm, Technische Hochschule Aachen, West Germany 
Tich T. Dao, Quaternion Technology, Inc. 

Ahmed M. Darwish, University of California, Davis 

Chitaranjan Das, Pennsylvania State University 

Surapol Dasananda, Santa Clara University 

Sumit Dasgupta, IBM Corporation 

Subrata Dasgupta, University of Southwestern Louisiana 

Gabor David, Technical University of Berlin, West Germany 

Evan Davidson, IBM Corporation 

Scott Davidson, AT&T Technologies Engineering Research Center 
Marc Davio, Philips Research Laboratory, Belgium 
Alan M. Davis, BTG, Inc. 

Robert L. Dawes, Martingale Research Corporation 

David S. Day, University of Massachusetts 

Judith E. Dayhoff, Judith Dayhoff Associates, Inc 

W. de Jonge, Vrye Universiteit, The Netherlands 

Juan De La Puente, Universidad Politechnica De Valencia, Spain 

Narayan Debnath, University of Wisconsin-River Falls 

Michael M. Dediu, Dediu Computer Consultants 

Stephen E. Deering, Stanford University 

Pierpaolo M. Degano, Universita di Pisa, Italy 

Norman Delisle, Tektronix, Inc. 

Jean-Marc Delosme, Yale University 
John Denker, AT&T Bell Laboratories 


Abdulilah Dewachi, Iformation Processing Centre, Iraq 

Jeff DeCurtins, SRI International 

Paul A.D. deMaine, Auburn University, Alabama 

Dave DeWitt, University of Wisconsin 

Dan Dias, IBM T.J. Watson Research Center 

Verlynda S. Dobbs, Wright State University 

Ernst E. Doberkat, University of Hildesheim 

Daniel R. Dolk, Naval Postgraduate School 

Jack Dongarra, Argonne National Laboratory 

Norbert Drescher, Techical University of Berlin, West Germany 

W.B. Dress, Oak Ridge National Laboratory 

Larry Druffel, CMU, Software Engineering Institute 

David Hung-Chang Du, University of Minnesota 

Michel Dubois, University of Southern California 

Robert A. Duisberg, Tektronix, Inc. 

Dick Dunn, Interactive Systems Corporation 
Lorraine M. Duvall, Duvall Computer Technologies, Inc. 
Wayne Dyksen, Purdue University 

Caroline Merriam Eastman, University of South Carolina 
Malcolm C. Easton, IBM Alamden Research Center 
Jurgen Ebert, EWH Koblenz, West Germany 
Richard H. Eckhouse, Jr., MOCO, Inc. 

Rolf Eckmiller, University of Dusseldorf, West Germany 

Costandin E. Economou, Athens, Greece 

Lionel N.M. Edward, University of Canterbury, New Zealand 

Margaret Eich, Southern Methodist University 

James L. Eilbert, Drexel University 

Lance B. Eliot, University of Southern California 

Carla Schlatter Ellis, Duke University 

Philip G. Emma, IBM T.J. Watson Research Center 

George Epstein, University of North Carolina, Charlotte 

Milos D. Ercegovac, University of California, Los Angeles 

Wolfram Ermel, International Robomation 

Okan K. Ersoy, Purdue University 

Daniel Etiemble, Universite Paris, France 
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C omputer programs, like many 
other dynamic and abstract pro¬ 
cesses, are often best understood 
by observing graphical simulations of their 
behavior. Graphical displays of a program 
in action expose some properties that we 
might otherwise find difficult to under¬ 
stand or even notice. Moreover, this com¬ 
munication medium becomes even more 
powerful if we interact with such anima¬ 
tions by controlling both the program 
being simulated and the way information 
is presented. Algorithm animation envi¬ 
ronments follow this paradigm for explor¬ 
ing computer programs. 

With the advent of workstations in the 
past five years or so, a handful of algo¬ 
rithm animation systems have been devel¬ 
oped and used for a variety of 
applications. For example, at Brown Uni¬ 
versity, Brown’s and Sedgewick’s Balsa 
was used for instruction in computer 
science courses (in particular, introductory 
programming, data structures, and 
graphics) and for research in the design 
and analysis of algorithms. 1 London and 
Duisberg at Tektronix used animated pro¬ 
grams for performance tuning and debug¬ 
ging of large systems, 2 and at Bell Labs, 
Bentley and Kernighan exploited animated 
displays for algorithm research and for 
generating sequences of static diagrams of 


An algorithm 
animation environment 
like Balsa-II provides 
an “exploratorium” 
for investigating the 
dynamic behavior of 
programs. It can 
fundamentally change 
and improve the way 
we understand and 
think about them. 

data structures. 3 

The Balsa-II algorithm animation sys¬ 
tem, a direct descendent of the Balsa sys¬ 
tem, 1,4 can be thought of as an extensible 
interpreter with graphical I/O. A user 
watches execution of an algorithm through 
various views. Each view is displayed in a 
window on the screen. The user can change 
the location and size of each window, 
zoom into the view to see more detailed 


information, pan over the image, and 
point at parts of the view in response to an 
algorithm’s request for information. Users 
can control the execution by single¬ 
stepping and setting breakpoints in terms 
of program-specific units, and can control 
how multiple algorithms are synchronized 
by manipulating the amount of time 
program-specific units take to execute. 

Balsa-II also provides a scripting facil¬ 
ity, that is, a recording of a user’s actions 
that can be replayed. However, rather than 
recording keystrokes, mouse activity, or 
graphical output primitives, it stores 
higher level information. Consequently, a 
script does not function merely as a pas¬ 
sively viewed videotape. Instead, the 
viewer of a script can also customize the 
videotape interactively, switching between 
passive viewing and active exploration. 

Balsa-II itself is domain-independent: It 
does not know whether an algorithm sorts 
numbers or produces random numbers, or 
whether a view shows a tree or a table. It 
does not attempt to decide what 
phenomena in a program are interesting, 
or what visual representations or styles of 
input are appropriate. Rather, it provides 
tools for programmers to animate 
algorithms with a modest amount of 
effort. Moreover, once the effort has been 
invested, users can reap the reward of run- 
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ning the algorithm using all of the Balsa- 
II facilities for controlling execution, 
managing the display, and scripting. 

How much effort is required to animate 
an algorithm? Briefly, animating an algo¬ 
rithm coded in Pascal, as found in a jour¬ 
nal article or textbook, involves three 
steps. 

The first step is to split the program into 
three components: the algorithm itself, 
various input generators that provide data 
for the algorithm to manipulate (exactly 
one input generator is specified by the user 
at runtime), and various views that pres¬ 
ent the animated pictures of the algorithm 
in action. Associated with each component 
are parameters—observable and modifi¬ 
able by users at runtime—to control 
aspects of the component. Using 
parameters to interact with .a program pro¬ 
vides a consistent framework for allowing 
users to specify various types of informa¬ 
tion when they want it, not when the pro¬ 
gram wants it. 

The second step is to implement each 
component. In practice, input generators 
and views are not implemented for each 
algorithm anew, but existing components 
are accessed from a library of such com¬ 
ponents. Implementing the algorithm 
involves, for the most part, annotating the 
code with interesting event markers. An 
interesting event takes the form of a proce¬ 
dure call to a system routine whose 
parameters are the name of the event and 
any arguments associated with the event. 

One type of interesting event, an output 
event, corresponds to the points at which 
a Writein might have been placed for 
debugging, tracing, or generating output 
of the algorithm in a nongraphical envi¬ 
ronment. When the program runs within 
Balsa-II, to a first approximation, all views 
on the screen are notified whenever an out¬ 
put event occurs and each view updates 
itself as appropriate to reflect the event. 

The other type of interesting event, an 
input event, corresponds to the place at 
which a Readln might have appeared in a 
conventional implementation of the algo¬ 
rithm. During execution, the input gener¬ 
ator chosen by the user is notified of each 
input event and responds by returning 
some data to the algorithm. 

The third step is to identify for Balsa-II 
those views and input generators that can 
be used with each algorithm, and to give 
textual names for each algorithm, input 
generator, and view. The textual names are 
presented to users at runtime in various 
menus. In addition, the interesting events 
must be identified to Balsa-II and given 


textual names. Users access the events as 
the program-specific units for controlling 
the interpreter. 

Overall, the learning curve for Balsa-II 
programmers is probably a bit steeper than 
that of other algorithm animation sys¬ 
tems. 2,3,5 ‘ 7 However, the extra effort 
seems defensible given Balsa-II’s facilities 
for manipulating program displays and 
execution, and for scripting. 

The bulk of the effort for a typical 
Balsa-II programmer involves annotating 
the algorithm being animated. The anno¬ 
tations essentially identify the fundamen¬ 
tal operations in the algorithm, which, in 
general, cannot be inferred automatically. 
It is not too surprising, therefore, that 
other algorithm animation systems require 
roughly the same overhead for annotating 
algorithms. 

In this article, I make a distinction 
between users, who watch and interact 
with the simulations, and programmers, 
who implement the algorithms, input 
generators, and views that the users see 
and manipulate. This distinction is really 
one of nomenclature, intended to help 
make the presentation clearer than it 
otherwise could be. Typically, a single per¬ 
son is both programmer and user, readily 
switching between the two roles. Unfor¬ 
tunately, the transition between user and 
programmer is not completely transpar¬ 
ent: Programmers currently edit and com¬ 
pile components outside of Balsa-II using 
standard editors and compilers in conjunc¬ 
tion with a Balsa-II preprocessor. Their 
code is linked with Balsa-II, the Balsa-II 
application is invoked, and the program¬ 
mer becomes a user. 

This article is organized in two major 
sections. We will look at Balsa-II first 
from a user’s perspective and then from a 
programmer’s perspective. The two parts 
should be read in this order because the 
programmer’s model assumes some 
understanding of the types of things users 
can do. Also, a number of the examples 
shown from the programmer’s perspective 
are the (simplified) implementations of 
things previously shown from the user’s 
perspective. 

Bear in mind that this article is not 
meant to be a user’s manual or program¬ 
mer’s manual for the Balsa-II system. For 
this reason I have glossed over many 
implementation details (such as the Balsa- 
II preprocessor and identifying compo¬ 
nents for Balsa-II) to concentrate on fun¬ 
damental concepts. Also, because of space 
limitations, I do not discuss scripting or 
implementation aspects of Balsa-II itself. 


The interested reader should consult A Igo- 
rithm Animation . 8 


User’s perspective 

Balsa-II users follow a setup-and-run 
style of interaction. In the setup phase, the 
user arranges windows on the screen and 
chooses the algorithms to run, the input 
generator to use for each algorithm, the 
views to see of each algorithm, and the 
values of the parameters associated with 
each algorithm and its input generator and 
views. In the run phase, the user runs the 
algorithms and watches execution through 
the views. While the algorithms are run¬ 
ning, the user can suspend them to change 
the ensemble of views on the screen or the 
interpreter’s controls. 

Before describing the interactive envi¬ 
ronment, three disclaimers merit mention. 

First, this article assumes some familiar¬ 
ity with the basic Macintosh user interface, 
including notions such as pull-down 
menus, expand boxes, and dialog boxes. 
It also assumes familiarity with general 
workstation terminology, such as double¬ 
clicking, windows, and dragging. 

Second, the diagrams in this article can¬ 
not, of course, give the “feel” of the inter¬ 
active environment. They do, however, 
indicate most of what can be done with it. 

Third, I have used common algorithms 
and fairly obvious displays in this article 
to enable you to concentrate on Balsa-II 
rather than on understanding the 
algorithms or the displays. Some addi¬ 
tional information about the algorithms 
and displays appears in the figure cap¬ 
tions; you can find details in many text¬ 
books, such as Algorithms . 9 Unfortun¬ 
ately, limiting myself to common 
algorithms makes some of the explorations 
look circumscribed at times. 

Basic tour. The elementary facilities 
found in Balsa-II include selecting an algo¬ 
rithm to run, starting and stopping execu¬ 
tion, selecting the views in which to see an 
algorithm’s execution, and managing win¬ 
dows on the screen. 

The menu bar contains the names of 
eight pull-down menus. At the far left, 
marked by the Apple Computer logo, is 
the standard Macintosh menu containing 
desk accessories. The File menu contains 
primarily commands for scripting, which 
are beyond the scope of this article. The 
Edit menu contains the standard Macin¬ 
tosh entries for text editing (such as cut, 
paste, and copy). However, since Balsa-II 
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Visualization of 
algorithms 

The images on this page (and on the 
cover of this issue of Computer) are rep¬ 
resentative of research that Bob Sedge- 
wick and I have been conducting on 
capturing the entirety of an algorithm in 
a single, static picture. 

Figure A shows Kruskal’s algorithm 
for finding the minimum spanning tree 
of a large undirected graph (2,000 nodes 
and 10,000 edges), about two-thirds 
complete. The edges of the graph are 
displayed as thin black lines and those 
on the spanning tree, as tfrick magenta 
lines. The same algorithm—but operat¬ 
ing on a much smaller graph (approxi¬ 
mately 280 nodes and 340 edges 
representing the Paris Metro system) 
and on a much lower resolution output 
device—appears as Figure 21 of this 
article. (The image was produced with 
the assistance of Sarantos Kapidakis.) 

Figure B depicts the entire operation 
of Heapsort. Each row shows the con¬ 
tents of the array being sorted at each 
step of the algorithm, from bottom (the 
initial, random array) to top (the final, 
sorted array). The color ranges cor¬ 
respond to the way that Heapsort uses 
pieces of the array: Elements in their ini¬ 
tial positions are colored in the green- 
cyan range. As elements are put on the 



Figure B. Heapsort. 



Figure A. Minimal spanning tree using Kruskal’s algorithm. 


heap, they are shown in the yellow-red 
range. When taken off the heap, they 
take on the blue-magenta range. Within 
each range, the value of the element 
corresponds to a color within the range. 
That is, green, yellow, and blue ends of 
the ranges are small elements; cyan, 
red, and magenta are large elements. 
The center marker indicates the opera¬ 
tions performed on each element during 
each step: white markers represent 
exchange operations and black markers, 
comparisons. 

Figure C displays a depth-first traver¬ 


sal of a random maze, starting in the 
lower left corner. Colors spanning the 
spectrum from red to blue are used to 
illustrate the first time that each path in 
the maze is traversed. 

Figure D is a representation of the 
Towers of Hanoi problem with seven 
disks and three pegs. The disks start on 
the blue peg and move to the yellow 
peg, using the red peg for temporary 
storage. A row is started after each 
move (from bottom to top) and the color 
intensity of the disk corresponds to its 
size. 



Figure C. Depth-first traversal of a maze 



Figure D. Towers of Hanoi. 
































Figure 1. Insertion sort. Insertion sort oper¬ 
ates by putting the At th element into proper 
position with respect to the first k - 1 ele¬ 
ments, which are already in proper relative 
order. The Sticks view on the left represents 
the array being sorted as a set of sticks whose 
heights correspond to their values, with a rec¬ 
tangle drawn beneath a stick when it is pro¬ 
cessed. The Compare-Exchange view on the 
right shows Insertion sort’s fundamental 
operations: comparisons and exchanges. 
Comparisons are represented by gray circles 
and exchanges by black ones. A row is started 
each time an array element is processed, 
thereby showing a history of the algorithm’s 
execution. 


windows are not text- or graphics-editing 
windows, this menu is rarely used. The 
Run menu contains commands for con¬ 
trolling the Balsa-II interpreter (the 
“Advanced tour” section discusses the 
interpreter in detail). The Windows menu 
(discussed later in this section) is used for 
display management. The Algs, Views, 
and Inputs menus each contain a list of 
available algorithms, views, and input 
generators, respectively. The first item in 
each of these three menus, Parms..., is 
used to set or observe values of the 
parameters associated with the selected 
algorithm, view, or input generator, 
respectively. The “Intermediate tour” sec¬ 
tion focuses on using input generators and 
setting parameters for algorithms and 
input generators. 

Algorithm and views. Let’s begin by 
choosing a common algorithm, Insertion 
sort. We pick the item Insertion Sort from 
the Algs menu and the screen arranges 
itself to contain two view windows: the 
Sticks at the left and the Compare- 
Exchange at the right. We start running the 
algorithm using the Go command found 
in the Run menu. Figure 1 shows the screen 
as Insertion sort is running. We can sus¬ 
pend a running algorithm at any time by 
a mouse click, and resume it by using Go 
again. 

We can change the algorithm being run 
by picking the desired algorithm from the 
Algs menu. Figures 2 and 3 show default 



Figure 2. Selection sort. Selection sort first finds the smallest item and exchanges it 
with the item in the first position. Then it finds the second smallest element and 
exchanges it with the item in the second position. It continues finding the smallest 
remaining item, exchanging it into its final position, until the sort is complete. 

The stick highlighted in gray is the current minimum. A gray mask, whose height 
corresponds to the value of the current minimum, slides to the right as each of the 
remaining elements of the array is considered. 

The fact that Selection sort is an N 1 algorithm can be easily verified by the fol¬ 
lowing geometric argument concerning the Compare-Exchange view: Ignoring the 
top row, which shows the initial contents of the array, there are N(N- 1) potential 
icons. A bit more than half of those will be filled with icons representing program 
operations. 
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Figure 3. Quicksort (Dots view). Quicksort 
partitions the array being sorted into two 
parts: all elements to the left of a “pivot” ele¬ 
ment are smaller than the pivot element, 
whereas all elements to the right of the pivot 
element are larger than the pivot element. The 
two subfiles are then sorted recursively. 

The Dots view displays a square for each 
element of the array being sorted: the 
horizontal coordinate corresponds to its posi¬ 
tion in the array and the vertical corresponds 
to its value. We can think of the dots as the 
tops of the sticks in the Sticks view. If fewer 
elements were being sorted, or if the window 
were larger, then a letter identifying each ele¬ 
ment would be visible. 




Figure 4. Quicksort (Sticks view). As mentioned in Figure 3 concerning the Dots 
view, if fewer elements were being sorted, or if the window were larger, then a let¬ 
ter identifying each element would be displayed at the top of each stick (see 
Figure 1). 


displays of Selection sort and Quicksort in 
action. 

Note that the default display for Quick¬ 
sort operates on a much larger set of data 


than either Insertion or Selection sorts, 
and it uses the Dots view rather than the 
Sticks view. The Dots view makes distinc¬ 
tive rectangular blocks of dots correspond¬ 


ing to subfiles waiting to be processed. 

A fundamental thesis of an algorithm 
animation system is that a single view of an 
algorithm or data structure does not tell a 
complete story. As a case at point, let’s 
change from the Dots view to the familiar 
Sticks view. We do this by clicking in the 
window containing the Dots view (its bor¬ 
der becomes highlighted), then choosing 
the desired view from the Views menus. 

When we choose the Sticks view, as 
shown in Figure 4, we are disappointed. 
Because of the amount of data, the sticks 
overlap and the subfiles awaiting process¬ 
ing are no longer prominent. However, the 
Partition-Tree view shown in Figure 5 is an 
interesting choice for displaying Quicksort 
because it not only shows the subfiles 
awaiting processing, but also gives an indi¬ 
cation of how well Quicksort’s partition¬ 
ing phase is working. Good partitions are 
reflected by well-balanced trees. 

In fact, a reasonable exercise suggested 
by this display is to run Quicksort on a file 
in reverse order or on one already sorted 
to verify that a degenerate tree results. We 
would do so by selecting the input gener¬ 
ator Reverse or Sorted from the Inputs 
menu; these mechanisms are described in 
the next section. 

As Figures 1 and 2 showed, it’s often 
helpful to see multiple views of an algo¬ 
rithm simultaneously. We can create addi¬ 
tional view windows by using the View 
Windows... command found in the Win¬ 
dows menu. When we do this, the dialog 
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Figure 5. Quicksort (Partition-Tree view). The 
Partition-Tree view displays each array ele¬ 
ment as a node in a tree. The horizontal coor¬ 
dinate for each node corresponds to its 
position in the array. Circular nodes have 
been used as partitioning elements, and they 
are in their final, sorted positions in the array. 
The contiguous square nodes represent sub¬ 
files waiting to be processed; their depths indi¬ 
cate in what order they will be processed. 
From this static picture, it is apparent that 
this version of Quicksort is processing the 
smaller subfile before the larger one. 

The correspondence between the average 
number of partitioning steps and the average 
shape of a binary tree is a fascinating part of 
any thorough analysis of Quicksort’s perfor¬ 
mance. This view, quite specialized for Quick¬ 
sort, helps to illustrate the correspondence. 


box shown in Figure 6 appears. It contains 
icons for the available ways to tile the 
screen with view windows. 

Figure 7 shows the screen after we have 
chosen the new configuration of view win¬ 
dows, specified which view should go into 
the new window, and let the Quicksort 
algorithm run some more. As the program 
runs, all views are updated simultane¬ 
ously. They represent the current state of 
the algorithm and its data structures. 

Display management. All view windows 
on the Balsa-II screen are contained within 
an algorithm window. All figures thus far 
have shown exactly one algorithm window 
that happens to comprise the entire screen 
except for the menu bar. Double-clicking 
on either an algorithm window or a view 
window causes its window dressing to be 
drawn (or erased, if it is currently dis¬ 
played). Algorithm window dressing con¬ 
sists of a number in the upper right corner 
indicating how much “time” the algo¬ 
rithm has consumed. (The “Advanced 
tour” elaborates on the notion of time in 
Balsa-II.) Figure 8 shows some windows 
with their dressings displayed. 

View window dressing consists of a title 
bar, three scroll bars, and various icons. 
Following Macintosh conventions, the 
title bar is used for moving windows, the 
close box at the left edge of the title bar is 
used for removing windows from the 
screen, and the expand box at the right 
edge of the title bar is shorthand for chang- 



Figure 6. Creating view windows. A tiling configuration of view windows is chosen 
by double-clicking on the appropriate icon or by selecting it followed by clicking on 
the OK button. 


ing a view window to encompass the entire 
algorithm window, or returning the win¬ 
dow to its previous location. 

Changing the size of a window using the 
size box in the bottom right does not cause 


the contents to be rescaled; it just controls 
how much of the underlying image can be 
seen. The rescale box in the lower left cor¬ 
ner of the view window causes the contents 
of the view to be rescaled to fit the current 
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Figure 7. Multiple views of Quicksort. At the 
left, the Dots view (see Figure 3); at the right, 
the Partition-Tree view (see Figure 5). 




File Edit Run Windows Rigs Uieivs Inputs k 



Figure 8. Managing view windows. Management of view windows follows Macin¬ 
tosh conventions with three additions: (1) The zoom bar on the left side of the win¬ 
dow (it looks like a standard scroll bar) enlarges the image and increases the level of 
detail displayed. (2) The rescale box in the lower left corner scales the image to the 
current shape of the view window and resets the zooming and panning scroll bars. 
(3) View windows are arranged hierarchically within algorithm windows (thus far, 
all figures have shown just a single algorithm window that encompasses the entire 
display). 


view window. 

When the window is small or the 
amount of data is large, the data is dis¬ 


played in miniature with information sup¬ 
pressed. We can enlarge parts of the 
display by using the zoom bar on the left 


of the view window, and can scroll 
through the display using the scroll bars at 
the right and at the bottom. Zooming is a 
logical operation. It does not merely mag¬ 
nify the pixels on the screen, but rather 
causes more and more information to be 
displayed. The nature of the additional 
information depends on the view. As 
shown in Figure 8, zooming into the par¬ 
tition tree reveals identifiers for each node. 

View parameters. We can control vari¬ 
ous attributes of how information is dis¬ 
played in a particular view window 
through the notion of view parameters. If 
we choose the Parms... command in the 
View menu, a dialog box appears with the 
various options. The options apply only to 
the selected view window, that is, the view 
window where we last clicked on the 
mouse. 

It is important to realize that Balsa-II 
just provides a framework: The nature of 
the parameters available for each view 
depends on the programmer who imple¬ 
mented that view. For example, in the 
Dots view from before, one of the view 
parameters determines whether the 
“dots” should be squares or circles. Or, in 
the Partition-Tree view, as shown in Fig¬ 
ure 9, the view parameter determines 
whether sibling nodes should be coalesced 
into a single node or displayed 
individually. 

Multiple algorithms. Just as we can tile 
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Figure 10. Multiple algorithms: Shellsort, Heapsort, Quicksort, and Mergesort. 
This snapshot was inspired by the finale of Baecker’s and Sherman’s terrific movie 
concerning sorting algorithms. Sorting Out Sorting.™ 


an algorithm window with view windows, 
so can we tile the screen with algorithm 
windows. We do this by selecting the Alg 
Windows... command from the Windows 
menu. The Go command starts all 
algorithms running simultaneously. 

Actually, Balsa-II provides quite a bit of 
control over how the algorithms should be 
synchronized; these facilities are described 
in the “Advanced tour” section. Figure 10 
shows the screen with four sorting 
algorithms running simultaneously. The 
static picture of the dots is very distinctive, 
but the dynamics are even more so. 

As mentioned, there is always a selected 
view window. The topmost view window, 
it belongs to the selected algorithm win¬ 
dow. Clicking in an algorithm window 
causes it and its most recently selected view 
to become selected. The selected algorithm 
and view are important notions because 
many commands apply only to them. 

Algorithm windows, unlike view win¬ 
dows, cannot be moved, sized, or deleted; 
rather, a new tiling strategy for the screen 
is chosen. At first glance, this design deci¬ 
sion seems overly restrictive. In practice, 
however, users seem comfortable with 
Balsa-II’s amalgamation of tiling and 
overlapping paradigms. 

Intermediate tour. In this section, we 
focus on Balsa-II facilities for tuning 
algorithms through parameters and for 
specifying data that algorithms manipu¬ 
late. Users provide data in three ways: by 


specifying an input generator to be used by 
the algorithm, by tuning an input genera¬ 
tor through its parameters, and by 
responding to requests for information 
while programs are running. 


Algorithm parameters. Algorithm 
parameters affect the algorithm, not the 
data that the algorithm manipulates. For 
example, should the lexical analyzer in an 
animated compiler use a hash table of size 


May 1988 


































Figure 11. Different algorithm parameters for 
Quicksort. The version of Quicksort at the far 
left is the naive version. The middle and right 
versions ignore small subfiles and then call 
Insertion sort on the “almost sorted” array. 
The middle algorithm considers small subfiles 
to be of size 7 or less, whereas the right ver¬ 
sion uses a cutoff of 25. The right version is in 
the process of the Insertion sort phase: about 
20 percent of the elements have been pro¬ 
cessed. Although it is not obvious in this static 
image, the middle version will be the first to 
finish. 

The HBars view displays each element of 
the array as a horizontal bar whose length 
corresponds to the element’s value. When the 
array is sorted, a filled-in “V” will result. 




leftmost element, rightmost element, or 
median-of-three element), and the subfile 
to process first (the left, right, or smaller 
of the two). In Figure 11, we see the effect 
of varying one of these algorithm 
parameters. The three versions of Quick¬ 
sort are processing the same set of data, 
but each uses a different value for deter¬ 
mining the size of subfiles to ignore and 
leave for the final pass using Insertion sort. 

We can observe the values of the 
selected algorithm’s parameters using the 
Parms... button in the Algs menu. Figure 
12 shows the dialog box used for observ¬ 
ing the Quicksort algorithm parameters. 
Unlike view parameters, algorithm 
parameters can only be modified before 
the algorithm starts running. If the 
parameters were modifiable—that is, if we 
were in the setup rather than the run 
phase—the Cancel button in the dialog 
box in Figure 12 would be replaced by an 
OK button. 


Figure 12. Specifying algorithm parameters for Quicksort. The parameters avail¬ 
able for tuning Quicksort programs are: the size of small subfiles to be ignored, the 
criterion for choosing a partitioning element, and the criterion for choosing which 
subfile to process first. The dialog box shows the parameter values for the selected 
algorithm, that is, the algorithm (at the far right) whose banner is highlighted. 


119 or 2001 ? Or should it use a binary tree 
(or some specific type of balanced tree) 
rather than a hash table? 

The Quicksort algorithms from the 


earlier figures have three parameters: the 
size of subfiles that should be ignored by 
Quicksort and left for a final Insertion sort 
pass, the type of partitioning strategy (the 


Input generators. Input generators pro¬ 
vide the data for an algorithm to process. 
For the sorting algorithms we’ve inves¬ 
tigated thus far, the input generator has 
produced a random permutation of keys. 
Other input generators for sorting 
algorithms include a random set of keys 
within a specified range and allow for 
duplicate keys, an increasing or decreasing 
set of keys, a set of numbers stored in a 
file, and a set of keys that is “almost” 
sorted. 
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Figure 13. Input generator Almost Sorted for 
Insertion sort and Quicksort. The Inversion 
Table view at the bottom of each algorithm 
window indicates how close each element of 
the array is to being sorted. More precisely, 
the stick for element i has length proportional 
to j if there are j elements larger than the ith 
element in positions 1 through /- 1. 


We choose an input generator other 
than the default by selecting from the 
Inputs menu. In Figure 13, we have picked 
the input generator Almost Sorted from 
the Inputs menu for both Quicksort and 
Insertion sort; Insertion sort isn’t doing 
too badly! 

It’s frequently useful to run an algo¬ 
rithm simultaneously on different input 
generators to illustrate its particular 
properties. In Figure 14, for instance, 
Shellsort on top is running on a set of num¬ 
bers in decreasing order; on the bottom, it 
is running on a random set of numbers. 
We can see that Shellsort performs 
reasonably well on the degenerate case of 
a reverse sorted file. (In fact, a challeng¬ 
ing exercise is to find the worst-case input 
for Shellsort as a function of the increment 
sequence used.) 

Input generator parameters. Input 
generator parameters govern the type of 
data that an input generator provides to 
the algorithm. For example, the parame¬ 
ter to an input generator that reads data 
from a file might be the name of the file. 
The parameters to an input generator that 
generates a random permutation of 
integers, such as those shown in Figure 12, 
consist of the size of the permutation and 
a seed for the random number generator. 

Running an algorithm with the same 
input generator, but with different param¬ 
eter values, often illustrates specific 
properties of an algorithm. For example. 



Figure 14. Shellsort running with different input generators. Shellsort is a simple 
modification to Insertion sort: Rather than putting the Ath element into proper 
position relative to the first A -1 elements, the Ath element is put into proper posi¬ 
tion relative to the (A-A)th, (A-2*/»)th, (A-3*/i)th, . . . elements. Multiple passes 
through the array are made, each time with a smaller value of h, until h = 1. 

Both versions of Shellsort are using the increment sequence (that is, the values of 
h) 121, 40, 13, 4, and 1. The version at the top is processing a file in reverse order; 
the version at the bottom is processing a file containing a random permutation of 
keys. 

In the HBars-History view, the column of bars at the far right corresponds to the 
current contents of the array being sorted. A copy of the view is made and slid to 
the left when each Shellsort increment is processed. When Shellsort finishes, the 
column at the right will look like the letter “V” (see Figure 11), whereas the 
column at the left will show the initial contents of the array. 
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Figure 15. Input generator parameters for 
Almost Sorted. All three versions of Insertion 
sort are processing a file that is “almost 
sorted.” In the top version, each key is no 
more than seven elements away from its final, 
sorted position. In the middle version, ele¬ 
ments are up to 25 positions away, and in the 
bottom version, 75 positions away. 




Figure 16. Specifying input generator parameters for Almost Sorted. The 
parameters available for tuning the input generator Almost Sorted are: the size of 
the array to sort, a seed for the random number generator to use, and how “almost 
sorted” the array should be. 

The dialog box shows the parameter values for the input generator associated 
with the selected algorithm, that is, the algorithm (at the bottom) whose banner is 
highlighted. 


in Figure 15, the same algorithm. Insertion 
sort, is running with the same input gener¬ 
ator, Almost Sorted, but each instantia¬ 


tion has different values for the input 
generator parameter that specifies how 
“almost” sorted the file is. It is clear— 


even from the static display—that Inser¬ 
tion sort performs exceptionally well when 
the file is close to sorted. (This property of 
Insertion sort was hinted at in Figure 13.) 

Values of input generator parameters, 
like algorithm parameters, cannot be 
changed while algorithms are running, 
only before they start. However, we can 
observe the values of both types of 
parameters while the algorithms are run¬ 
ning (see Figure 12). The dialog box that 
allows us to set or observe the input gener¬ 
ator parameters is shown in Figure 16. The 
dialog box is displayed in response to 
selecting Parms... from the Inputs menu. 

Runtime specifics. In some situations, 
information for an algorithm or input 
generator cannot be specified before a pro¬ 
gram runs—for example, picking a node 
to delete in a binary tree—because the 
information is based to some extent on the 
current runtime state of the algorithm. In 
another example, shown in Figure 17, a 
graph traversal algorithm prompts the user 
to select a vertex at which the traversal will 
begin. 

Alternatively, this information could 
have been considered a parameter of the 
input generator. Doing so, however, 
would preclude using the assortment of 
graph views for specifying the infor¬ 
mation. 

Information specified by the user while 
the algorithm is running is called runtime- 
specific. In Figure 17, for instance, we see 
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Figure 17. Runtime-specifics for graph traver¬ 
sal algorithms. The Graph view at the left dis¬ 
plays an undirected graph. Circles represent 
vertices in their initial state. The Adjacency 
Matrix view at the right shows a marker at 
position (x,.y) iff there exists a directed edge 
between the xth and yth vertices. 

The program has run through its initializa¬ 
tion and has paused, awaiting user response to 
identify a vertex. The selected vertex is D, 
highlighted in both views. 


that this information can be specified tex- 
tually (by typing a vertex name in response 
to the prompt in the menu bar) or graphi¬ 
cally (by using the mouse to click on an 
object corresponding to a vertex in any of 
the views). Obviously, graphical input is 
not necessarily meaningful in every view. 

It is important to realize that the user 
cannot give such information to the algo¬ 
rithm at all times. Runtime-specific infor¬ 
mation is specified only in response to a 
request by the algorithm. Algorithm and 
input generator parameters, on the other 
hand, can be specified at any time before 
the algorithm starts running, and view 
parameters can be specified any time at all. 

Advanced tour. In this section, we look 
at how users control the Balsa-II inter¬ 
preter and scheduler, and at some features 
important to people studying algorithms 
in detail. 

Execution styles. The Balsa-II inter¬ 
preter allows execution to be controlled in 
terms of program-specific units, namely 
the interesting events with which a pro¬ 
grammer has annotated the algorithm. For 
each event, we can specify whether it 
should be used as a stop-point or as a step- 
point. A stop-point is analogous to a 
breakpoint in conventional debuggers: 
When the specified event has occurred the 
specified number of times, the interpreter 
pauses execution. A step-point is a gener¬ 
alization of a conventional debugger’s 



Figure 18. Costs, stops, and steps. The dialog box shows the interesting events for 
graph traversal algorithms. The check box immediately to the left of each event 
indicates whether that event is in the set of events that constitute the next “step.” 
The value to its left indicates how many events of that type should occur before a 
“stop” occurs. At the far left is the “cost” assigned to it. 


notion of “step to the next line.” That is, 
when we issue the “single step” command, 
the interpreter advances to the next event 
specified as a step-point. 


The Stops... command in the Run menu 
brings up the dialog box shown in Figure 
18 for observing and specifying this infor¬ 
mation. Following MacPascal" terminol- 
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Figure 19. Execution styles. These basic graph 
views (see Figure 17) show a larger graph than 
before. The display style of each vertex and 
edge indicates its state. Hollow circles are ver¬ 
tices that have not been visited, gray squares 
are vertices on the priority queue data struc¬ 
ture ready to be visited in the near future, and 
black squares are vertices that have been 
visited. The display style of the edge (reflected 
in both views, but difficult to make out in the 
Adjacency Matrix view) indicates how it was 
used to select which vertex to process. 




Figure 20. Event costs. This dialog box is displayed as a result of selecting the Show 
Counts button in the Stops... dialog box from Figure 18. The display shows the 
number of times each event has occurred (left), the sum of which equals the 
algorithm's event count, and also each event’s weighted count (right), the sum of 
which equals the algorithm’s virtual time. 


ogy, algorithms can be run in one of the 
four styles shown in Figure 19: Go stops at 
the next stop-point; GoGo pauses at stop- 
points; Step stops at the next step-point; 
and StepStep pauses at step-points. The 


Reset command terminates the execution 
of the selected algorithm. 

Scheduling multiple algorithms. Simply 
watching an algorithm in action may, at 


times, lead to mistaken impressions con¬ 
cerning its performance because the time 
required by the graphics performed in each 
view may dwarf the algorithm’s computa¬ 
tion time. Moreover, as more view win¬ 
dows are opened, the algorithm necessarily 
appears to run slower! 

To precisely measure an algorithm’s 
performance, we can find the number of 
times each interesting event has occurred 
by issuing the Show Counts command 
found in the Stops... dialog in Figure 18. 
This information is shown in the left 
column of numbers in Figure 20. In prac¬ 
tice, interesting events correspond to an 
algorithm’s fundamental operations, and 
these numbers have immediate interest for 
people studying an algorithm’s per¬ 
formance. 

We can specify a cost for each event; 
intuitively, the cost is a measure of how 
much computer time the interpreter should 
allocate for the event. Figure 21 shows two 
instantiations of Kruskal’s algorithm for 
finding a minimal spanning tree in an 
undirected graph. Both versions have the 
same parameters, input generators, and so 
on, but they have progressed at different 
rates because different costs have been 
assigned to the events. This helps us simu¬ 
late the algorithm on two different models 
of computation. For example, in one 
model data movement might be expensive 
relative to data access, whereas in another 
model these operations might have the 
same relative cost. 
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Figure 21. Synchronizing multiple algorithms. 
Kruskal’s algorithm for finding the minimal 
spanning tree (MST) of a graph operates as 
follows: The weights along the edges are 
sorted and processed from smallest to largest. 
An edge is put on the MST if the vertices it 
connects are not already connected by edges 
on the MST. In this figure, the weight of each 
edge is the Euclidean distance between the two 
vertices it connects. 


Balsa-II schedules the multiple 
algorithms in a round-robin fashion. Dur¬ 
ing each time-slice, an algorithm executes 
until it reaches an event, then that event is 
broadcast by Balsa-II to all views so they 
can update themselves. (I will elaborate on 
the broadcast process in the next section.) 
If the cost for the event is W, then that 
algorithm misses its next W- 1 time-slices. 

Two additional terms are helpful for a 
complete understanding of Balsa-Il’s 
scheduler: the event count of an algorithm 
is the number of events that have occurred, 
and the virtual time is the weighted sum of 
the events. More precisely, let W(e) repre¬ 
sent the cost associated with event e, let 
N(e ) be the number of times event e occurs 
when an algorithm is run, and let £ be the 
set of events that the algorithm contains. 
The event count, C, and the virtual time, 
T, are computed as follows: 

C= f I N(e) 
and 

T= I N(e) W(e) 

for all eeE 

It follows directly from Balsa-II’s 
scheduling algorithm that while multiple 
algorithms are running, their virtual times 
are identical. However, their event counts 
may not be. The virtual time, not the event 
count, is displayed as part of the algorithm 
window dressing. The right column of 
numbers in Figure 20 shows how much 
each event contributes to an algorithm’s 
virtual time. 


Programmer’s 

perspective 

Here we leave the realm of the Balsa-II 
user and enter that of the Balsa-II pro¬ 
grammer. Although I am devoting equal 
attention to implementing algorithms, 
input generators, and views, I must 
emphasize again that Balsa-II program¬ 
mers are mostly concerned with imple¬ 
menting algorithms. They access input 
generators and views from a library of 
such components. 

For programmers, Balsa-II’s primary 
goals are as follows: 

• Independent components. Code for 
algorithms, input generators, and views 
should be separate and independent. A 
programmer should be able to focus on the 
algorithm while completely ignoring the 
code required for its animation. Con¬ 
versely, he or she should be able to concen¬ 
trate on implementing the animated 
graphic display while completely ignoring 
the nature of the algorithms that might be 
used to drive the animation. 

• Minimal modifications. Changes 
made in an algorithm for animation 
should have minimal effect on the algo¬ 
rithm. All modifications should be 
denoted conspicuously, so that after the 
algorithm has been prepared for anima¬ 
tion, it can easily be returned to its origi¬ 
nal state. 

• Reusable components. Once an algo¬ 


rithm, input generator, or view is imple¬ 
mented, its interface should be frozen and 
it should become part of a library of such 
components. Adding, changing, or delet¬ 
ing an algorithm, input generator, or view 
from the library should not affect existing 
components. Moreover, it should be pos¬ 
sible to use any particular view to display 
aspects of itself, other views, or multiple 
aspects of the same algorithm. 

• Easy implementation. Creation of a 
new algorithm, input generator, or view 
should be quick and easy. That is, the 
overhead required by using Balsa-II 
should be minimal. Of course, the more 
sophisticated an algorithm, input genera¬ 
tor, or view, the more time and effort 
required for its implementation. 

The examples presented in this part use 
simplified versions of the basic algorithms, 
input generators, and views that we have 
already seen from the user’s perspective. 
Animating a more complex algorithm, or 
designing a fancier version of an input 
generator or a view, follows the same 
model. 

Algorithms. Preparing an algorithm 
(coded in Pascal) as found in a textbook or 
journal article for animation in Balsa-II 
involves two steps: annotating and struc¬ 
turing. Annotating an algorithm involves 
inserting interesting event markers. Struc¬ 
turing an algorithm involves creating entry 
points called by Balsa-II in response to 
user actions, such as when the user speci- 
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procedure Alg.Quicksort.Code-, 
var i,j, v : Integer-, 

a : array[l.. AfaxJV] of Integer; 
eofFg : Boolean; 

procedure Quicksort^, r : Integer ); 
var v, t,i,j : Integer; 

begin 

if r — 1 > M then 
begin 

v := a[r]; i := 1 - 1; j := r; 

repeat i := i + 1 until a[i] > v; 
repeat j := j — 1 until a[i] < v; 
t := a[i]; a[i] := a[fl; a [/] := t; 
OutputEvent.Swap(iJ); 
until j < i; 

«W “ -M; «[i] := «[r]; := *; 

OutputEvent.Swap(iJ); 

OutputEvent.Swap(i,r); 

Quicksort(l,i — 1); 

Quicksort^ + l,r) 
end 

begin 

eofFg := InputEvent.HowManyKeys(N); 
for i := 1 to JV do 

eofFg := InputEvent.ReadKey(a[i]); 
for i :— { to N do 
OutputEvent.NewKey(i, a[i]); 
Quicksort(l,N); 

if M > 1 then Insertionsort(a, N); 


Figure 22. Quicksort algorithm with annotations. The output events are displayed 
with a gray highlighting; they have been added to the algorithm strictly for anima¬ 
tion. The input events would have appeared in the original version as Readln state¬ 
ments. Variable M— the cutoff for small subfiles—is an algorithm parameter, and 
Figure 23 shows how its value is observed and modified by users. To display the 
Partition-Tree view (see Figure 5), an additional event, ElementInPlace(<), would 
need to be inserted before the first recursive call to procedure Quicksort. 


fies an algorithm window to be filled with 
this algorithm, when the user deletes the 
algorithm, when the user wants to see or 
modify the parameters, when the user 
starts the algorithm running, and so on. 

Annotating an algorithm. There are two 
types of interesting event markers: Algo¬ 
rithm output events describe some segment 
of algorithm code, and algorithm input 
events describe what type of data an algo¬ 
rithm needs. 

An algorithm event has a name and a 
collection of parameters that provide addi¬ 
tional information concerning the interest¬ 
ing phenomena in the program. 
Parameters to output events are read-only. 


whereas parameters to input events can be 
read-only, read-write, or write-only. 

An output event causes each view to be 
notified with appropriate parameters to 
update itself. The algorithm is not con¬ 
cerned with what, if anything, happens in 
the graphical displays. An input event 
causes the input generator to be notified 
with appropriate parameters to return 
appropriate information in the read-write 
or write-only parameters. Each input event 
also returns a flag indicating whether the 
logical end of file was reached. The algo¬ 
rithm is not concerned with how the input 
generator computes the information, or 
what constitutes the logical end of file. 

Figure 22 shows an annotated version of 


Quicksort. The algorithm output events 
are denoted by the procedure call Out- 
putEvent.xxx, and input events by the 
function call InputEvent.yyy, where xxx 
and yyy are the event names. The periods 
are listed for documentation purposes; 
they have no syntactic or semantic mean¬ 
ing to the compiler. The bodies of these 
routines are not part of Balsa-II per se; 
rather, they are generated when the pro¬ 
grammer defines the events. 

More formally, we say that an 
algorithm’s repertoire contains the set of 
algorithm events that are used to annotate 
it. Algorithms with the same repertoire can 
be interchanged and can use the same col¬ 
lection of input generators and views. 

Just as there is no right or wrong way to 
break a program into subroutines, so there 
is no right or wrong set of algorithm events 
that constitute an algorithm’s repertoire. 
The repertoire encapsulates the operations 
and data requests of an algorithm. What 
constitutes an operation depends primar¬ 
ily on what is intended to be displayed, 
which, in turn, often depends on the 
intended use of the animations. However, 
the events constituting a repertoire do 
indeed affect both users and 
programmers. 

For users, the repertoire defines the level 
of abstraction they see. For example, sup¬ 
pose that instead of a single event with an 
array of N polygons as its parameter, there 
were/Vevents, each with a single polygon 
as its parameter. Users would then 
encounter multiple events, instead of a sin¬ 
gle event, that they could use for stepping, 
stopping, and so on. This is more or less 
desirable, depending on the intended use 
of the animation. Artificially biased com¬ 
parisons may result if algorithms that are 
run together use different repertoires. 

For programmers, the choice of events 
often influences their coding style. Algo¬ 
rithm events are independent of the data 
structures used in the implementation of 
the algorithms, input generators, and 
views. However, using data structures that 
differ significantly from those used by 
events may necessitate costly data con¬ 
version. 

Structuring an algorithm. The second 
step in preparing an algorithm for Balsa- 
II is to structure it. That is, the algorithm 
is separated into subroutines to handle the 
algorithm code (as was shown in Figure 
22), the algorithm parameters, and also 
initialization and termination. The 
subroutines are called by the algorithm 


COMPUTER 









animation system. They do not call each 
other, communicating instead through 
shared global data. 

Figure 23 shows the complete story for 
Quicksort. All subroutines—except the 
one to handle the gist of the algorithm (and 
the parameters, if any)—are optional. 

In an unstructured algorithm, at some 
point while the algorithm runs the user is 
prompted to specify information relating 
to algorithm parameters. In a structured 
algorithm, the user-interaction code for 
specifying algorithm parameters is broken 
out into its own subroutine. Consequently, 
the algorithm animation system lets a user 
specify, change, and review this informa¬ 
tion at will, not upon the algorithm’s 
demand. 

Placing initialization and termination 
code into separate subroutines does not 
represent a fundamental change in inter¬ 
acting with algorithms, as algorithm 
parameters do. Rather, it helps improve 
real-time performance, because garbage 
collection is not free, virtual memory is 
limited, and disk access is time- 
consuming. When an algorithm is run 
repeatedly, the algorithm can take advan¬ 
tage of the fact that it used some resources 
previously. The structuring also provides 
a convenient mechanism for each algo¬ 
rithm to “clean up” after it finishes— 
either because it came to the end or because 
the user aborted it using the Reset 
command. 

Discussion. Animating an algorithm 
that uses an existing repertoire involves 
two steps: structuring the algorithm and 
annotating it with event markers. A previ¬ 
ously structured and annotated algorithm 
can serve as a prototype. If, however, the 
algorithm is sufficiently different from 
previously animated algorithms, then the 
programmer must first define the algo¬ 
rithm events it needs. 

In practice, structuring an algorithm 
involves little work, because the subrou¬ 
tines other than the Code subroutine are 
optional. In fact, structuring an algorithm 
may well reduce the total effort for 
programmers: Because “extraneous” 
code is removed, it becomes easier for the 
programmer to concentrate on the heart of 
the algorithm and to share ancillary func¬ 
tions among other algorithms that have 
been animated. 

Annotating an algorithm is also 
straightforward once its repertoire has 
been defined. The input events typically 
replace the system-specific input state¬ 
ments and the output events replace the 




module Alg. Quicksort; 

var M : Integer-, { algorithm parameter } 
procedure Alg.Quicksort.Create-, 

{ This routine is called by BALSA-II once, before any of the other routines are called. } 
begin 

M := 1; { default value of parameter } 

procedure Alg.Quicksort.Dispose-, 

{ This routine is called by BALSA-II once, after all of the other routines are called. } 
begin end; 

procedure Alg.Quicksort.StartRun; 

{ This routine is called by BALSA-II each time the Quicksort algorithm begins running. } 
begin end; 

procedure Alg.Quicksort.EndRun- 

(This routine is called by BALSA-II each time the Quicksort algorithm finishes running. } 
begin end; 

procedure Alg .Quicksort. Farms; 

{ This routine is called by BALSA-II each time the user wants to observe or change } 

{the “algorithm parameters” for the Quicksort algorithm.} 

var newM : Integer; 

begin 

Write7n(‘Current cutoff for small files is ’,M); 
if BALSAModifyParmsFg then 
begin 

WriteIn(‘Enter new cutoff:’); Readln(newM); 
if newM > 0 then M := newM 

procedure Alg.Quicksort.Code; 

{ Here is what one intuitively thinks of as “The Quicksort Algorithm.” } 

{ This routine is called by BALSA-II each time the user issues a run command,} 

{ preceded by a call to ... StartRun and followed by call to ... EndRun routine. } 

See Fig. 22 


Figure 23. Quicksort algorithm after structuring. Unlike the version of Quicksort 
shown in the first part of this article (Figures 11 and 12), this version has a single 
algorithm parameter and does not use a dialog box when interacting with the user 
modifying or observing it. The Module statement and its corresponding End define 
a Pascal unit that can be compiled separately. 


system-specific output statements. More¬ 
over, one could legitimately contend that 
algorithms are better implemented by 
replacing system-specific input and output 
statements with event annotations—even 
if no algorithm animation is involved— 
because event annotations provide a flex¬ 
ible interface to the outside. By default, an 
external package could be linked with the 
algorithm to print the name of each event 
and its parameters. More interestingly, 
different external packages could be linked 
with the same algorithm for different uses. 
One such package might perform statisti¬ 
cal analysis on the distribution of events. 


Another package might generate static pic¬ 
tures of one or more data structures. 

When an annotated algorithm runs, it 
produces a sequence of input and output 
events. We call the output events with their 
parameters an algorithm trace. We can 
think of the views on the screen as an imag¬ 
ing of the algorithm trace. Thus, to the 
algorithm animation system and to the dis¬ 
plays, it does not matter in what language 
the algorithm was coded, or if the events 
correspond to anything meaningful in the 
algorithm, or even if the events are gener¬ 
ated at random. A practical use for an 
algorithm trace is to debug input genera- 
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module Input.SetOfKeys; 

r N : Integer, { parameter: how many numbers ir 


*} 


range : Integer; { parameter: range of the numbers } 
seed : Integer ; {parameter: seed for random number generator) 
ct : Integer; { how many numbers have been generated already } 
procedure Input.SetOfKeys.Create; 
begin 
N := 50; 

range := Maxlnt; 


procedure Input.SetOfKeys.Dispose; begin end; 


procedure Input.SetOfKeys.EndRun; begin end; 
procedure Input.SetOfKeys. Parms; 

allow user to observe or change values of N, range, and seed 

function Input .SetOfKeys .Data. HowManyKeys(var numPts : Integer) : Boolean; 

{ This routine is called by BALSA-II in response to the input event HowManyKeys. } 
begin 

numPts := N; 

return false { no logical EOF for this event} 


function Input.SetOfKeys.Data.ReadKey(vi 
{ This routine is called by BALSA-II 

v := (Random mod range); 


return (ct > N) { “has logical EOF been reached?” } 


Real) : Boolean; 
the input ever 


Figure 24. Input generator SetOfKeys produces a set of pseudorandom numbers 
within a specified range. An algorithm (such as Quicksort as shown in Figure 22) 
uses input event HowManyKeys to find out how many numbers will be generated, 
and it uses input event ReadKey to determine the next number. 


tors and views independently of the 
algorithm. 

Another practical use for an algorithm 
trace is to animate a complex algorithm 
that runs too slowly to produce real-time 
animations. An algorithm trace would be 
created off-line, say on a supercomputer, 
and then accessed by the workstation to 
give a real-time animation. Obviously, in 
such a situation users would not be able to 
change algorithm parameters or the data 
the algorithm processes; they could, how¬ 
ever, interact with the displays. 


Input generators. Like algorithms, 
input generators are built as collections of 
routines, each handling a particular func¬ 
tion. There are routines to handle input 
generator parameters, initialization, and 
termination. A collection of Data routines 
responds to algorithm input events. By 
convention, the suffix of the Data routine 
is the name of the event to which it 
responds. Thus, if an algorithm uses the 
input event yyy, the algorithm contains the 
statement InputEvent.yyyf...) and the 
input generator has a corresponding entry 


Input.zzz.Data.yyy(...), where zzz is the 
name of the input module. The calling 
sequences are identical. 

Figure 24 shows part of an input gener¬ 
ator, SetOfKeys, that can be used with the 
Quicksort algorithm from Figure 22. It 
generates a sequence of pseudorandom 
numbers within a specified range. The 
input generator parameters are the num¬ 
ber of elements to generate, the range of 
the elements, and a seed for the random- 
number generator. 

We characterize an input generator by 
a repertoire consisting of those input 
events to which it responds. Input gener¬ 
ators with the same repertoire can be inter¬ 
changed without affecting algorithms or 
views. Thus, SetOfKeys can be used with 
any algorithm that requires a set of num¬ 
bers to process, including all of the sorting 
algorithms we saw in the first part of this 
article. 

Input from views. When an input gener¬ 
ator allows a user to specify runtime- 
specific information graphically, by point¬ 
ing in a view window, the input generator 
must communicate with the views to corre¬ 
late what object(s) on the screen a user has 
selected. The communication process is 
analogous to the way algorithms use input 
events to request information from an 
input generator. However, in the case of 
an input generator requesting information 
from a view, the mechanism is through 
correlate messages rather than input 
events. (As we will see, a mechanism 
analogous to output events, called update 
messages, is used internally by views.) 

Messages and events are similar in the 
sense that they allow procedures written by 
a programmer to call another procedure— 
but without knowing the callee. Balsa-II 
takes care of the routing. However, the 
difference between messages and events is 
more than nomenclature: Users are aware 
of events, but not of messages. That is, 
events provide the abstraction of the algo¬ 
rithm through which the interpreter is con¬ 
trolled, whereas messages are an internal 
mechanism that allows input generators 
and parts of views to communicate. 

Figure 25 shows the high-level relation¬ 
ship among an algorithm, input generator, 
and five views. The views have an internal 
structure not shown in the diagram (but 
discussed in the next section). 

Views. We now focus on implementing 
the graphical displays. Because many of 
the concepts parallel those relating to 
algorithms and input generators, we will 
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briefly consider the similarities and then 
concentrate on those aspects peculiar to 
views. 

Recall that each view window on the 
screen contains a view of the algorithm 
chosen by the user from a list of potential 
views. At any given time, the user can 
change which view is displayed in any par¬ 
ticular window, create a new window, or 
change the size and location of a window. 
The user can zoom and scroll through any 
view, and can tune the characteristics of 
each view through its parameters. 

A dominant theme of Balsa-11 is the 
desirability of defining the views and the 
system in such a way that the programmer 
implementing a view need only code the 
particulars of the view; all window- 
management aspects, for example, are 
handled by the Balsa-11 system. Moreover, 
because sophisticated views are complex to 
implement (even with a reasonable 
graphics environment), an algorithm ani¬ 
mation system must allow views to be 
shared by many diverse algorithms. 

Each view has three primary tasks: 

(1) A view must be able to update itself 
incrementally each time an algorithm 
event occurs. Updates must be done in 
real-time. 

(2) A view must be able to redisplay 
itself completely in an arbitrarily sized rec¬ 
tangular window using its internal data 
structures. This allows efficient implemen¬ 
tation of zooming and panning while an 
algorithm is running. It also permits open¬ 
ing a new view or changing the view dis¬ 
played in a particular view window while 
an algorithm is running. 

(3) A view must be able to map coor¬ 
dinates from the screen into the objects 
that it displays in response to correlation 
messages from the input generator. 

None of these three tasks are absolutes. 
Users will nonetheless notice the effects of 
any missing functionality. For example, if 
a view cannot map coordinates—either 
because the feature was not implemented 
or because selecting objects is not 
meaningful in the view—users will not be 
able to point at objects in that view in 
response to runtime specifics. However, 
the view can still be used to display an 
algorithm’s behavior. 

To portray an image on the screen, 
Balsa-II follows a classical computer 
graphics paradigm of a modeler and a ren- 
derer. The modeler creates and maintains 
a model , an abstract representation of the 
information that the Tenderer draws on the 
view window. The model is based, to a first 



Figure 25. The relationship among an algorithm, input generator, and five views at 
a high level. The notation is as follows: Boxes represent components implemented 
by programmers. The view boxes are dotted to emphasize that their implementa¬ 
tion consists of a number of interacting components not shown here (see Figure 
26). Ovals represent parts of the algorithm animation system that route informa¬ 
tion among components. Shaded ovals route events and unshaded ovals route mes¬ 
sages. The solid paths indicate unidirectional flow of information, and the dashed 
paths indicate bidirectional flow. The view corresponding to the view window hav¬ 
ing the keyboard focus is highlighted. 


approximation, on the output events 
generated by the algorithms. A particular 
model might have many Tenderers, simul¬ 
taneously displaying different views in 
different view windows. Balsa-II differs 
fundamentally from traditional graphics 
techniques in the way that modelers can be 
composed to display views of views, 
including themselves. 

Modelers are separated from Tenderers 
for efficiency. The modeler performs the 
expensive storage or computation aspects 
of maintaining and updating the model, 
which is then drawn on the screen by the 
Tenderer. Multiple Tenderers—either mul¬ 
tiple instantiations of the same view or 
different, but similar, views—can use the 
same modeler. Thus, only a single model 
needs to be maintained for multiple views 
on the screen. 


Because the information in the stream 
of output events generated by an algorithm 
does not necessarily correspond to the 
information the modeler and the Tenderer 
need, an adapter is used to transform the 
data to the appropriate repertoire. The 
adapter allows views to be composed in 
interesting ways and to be reused exten¬ 
sively (as mentioned above). 

Basic concepts. To recap, a view is per¬ 
ceived very differently by users and by 
programmers. Users find a view neither 
composable nor decomposable; they 
choose it from a fixed list of possible views 
and see it in a view window on the screen. 
Programmers know that a view is com¬ 
posed of an adapter, a modeler, and a Ten¬ 
derer. A modeler computes a model based 
on update messages. The update messages 


May 1988 




















Figure 26. Relationship among algorithms, input generators, and components of 
the five views from Figure 25. 


that the modeler uses are called its reper¬ 
toire. Modelers that use the same reper¬ 
toire are called functionally equivalent. 

A Tenderer draws an image of the model 
computed by the modeler onto a view win¬ 
dow on the screen. It also maps a position 
on the screen into parts of the model. The 
Tenderer uses the same repertoire as does 
its modeler. In general, there are many Ten¬ 
derers associated with each modeler. Ren- 
derers that share a modeler are said to be 
functionally equivalent; Tenderers that use 
different but functionally equivalent 
modelers are said to be functionally 
similar. 

An adapter converts algorithm output 
events (from the algorithms) and correlate 
messages (from input generators) into cor¬ 
responding update messages and correlate 
messages in the modeler’s and Tenderer’s 
repertoire. Functionally equivalent 
modelers and Tenderers can share adap¬ 
ters. A separate adapter is needed for each 


group of functionally equivalent 
algorithms and input generators. 

Once the modeler and Tenderer for a 
view have been implemented, their inter¬ 
face is frozen. To use it, a programmer 
must write an adapter for each group of 
functionally equivalent algorithms which 
will use the modeler and Tenderer. The 
algorithm code is also frozen; adding a 
new view requires implementing an 
adapter, not modifying the algorithm. In 
practice, adapters are relatively easy to 
code. Many merely forward the incoming 
events as outgoing messages. 

Figure 26 shows how the views in Figure 
25 might be structured internally in a sit¬ 
uation with five view windows on the 
screen. The image in each view window is 
drawn by one of the Tenderers. From this 
diagram, we cannot tell whether Tenderers 
Renderer-1 and Renderer-2 are the same 
view or similar views that happen to share 
modeler Modeler-1. Likewise, we cannot 


say anything about Renderer-4 and 
Renderer-5, other than that they follow the 
same repertoire as Modeler-3 and render 
an image of the model that Modeler-3 
maintains. Modeler-1 and Modeler-2 use 
the same adapter, Adapter-1. Thus, their 
views, rendered by Renderer-1, 
Renderer-2, and Renderer-3, are all func¬ 
tionally equivalent. 

Adapters, modelers, and Tenderers are 
structured, much like algorithms and input 
generators, into collections of subroutines 
that handle particular functions. All three 
types of components contain routines to 
handle initialization and termination. In 
addition: An adapter contains a collection 
of Update routines that convert from algo¬ 
rithm output events to view update mes¬ 
sages, and a collection of Correlate 
routines that convert from input genera¬ 
tor correlate messages to view correlate 
messages. A modeler contains a collection 
of Update routines that maintain the 
model to be rendered. A Tenderer contains 
collections of Update and Correlate rou¬ 
tines, and also routines to handle refresh 
and view parameters. The collection of 
Update routines displays the incremental 
modifications to the model. The collection 
of Correlate routines converts coordinates 
on the screen into objects of the model. 
The Refresh routine renders the entire 
model. The Parameters routine handles 
the view parameters analogously to the 
way that algorithm and input model 
parameters are maintained. 

In certain circumstances, it is advisable 
to let a Tenderer maintain the model itself. 
One example is when a modeler supports 
a single Tenderer and the programmer 
anticipates at most one instantiation of the 
Tenderer on the screen at any given time. 
A modeler would also be unnecessary if 
the data structures needed for maintaining 
the model are insignificant in terms of 
computation time or space. 

A modeler that uses other modelers is 
called a submodeler. The primary purpose 
of a submodeler is efficiency: The modeler 
does the bulk of the work, while sub¬ 
modelers do the additional work needed 
for certain views. A submodeler is similar 
to a Tenderer in the sense that both can 
read, but not modify, their associated 
modeler’s data structures. When an 
update message occurs, the parent modeler 
is notified of the event first, then sub¬ 
modelers are notified in a breadth-first 
manner. Because a submodeler is itself a 
modeler, Tenderers and other submodels 
can be associated with it. 

The final basic concept relating to views 
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is that of chaining modelers together to 
form a “view of a view.” A modeler can 
be annotated with update messages in the 
same way that an algorithm is annotated 
with output events. A modeler based on 
update messages generated by another 
modeler is called a chained modeler. A 
modeler does not know if it is a chained 
modeler: It maintains a model based on 
update messages it receives, independent 
of how the messages are generated. A 
modeler can also be annotated with corre¬ 
late messages, thereby allowing a view 
associated with the chained modeler to be 
used to specify graphical runtime- 
specifics. 

Using existing views. Using a view that 
has already been implemented is straight¬ 
forward. The programmer merely imple¬ 
ments an adapter that converts output 
events generated by the algorithm into the 
update messages for the view’s modeler 
and Tenderer, and that converts correlate 
messages generated by the input model 
into correlate messages for the view’s Ten¬ 
derer. Once the adapter is written, all views 
whose modelers are functionally equiva¬ 
lent can also be used. 

Consider how we might utilize the famil¬ 
iar Sticks view to display the Quicksort 
algorithm from Figures 22 and 23. The 
Sticks view is part of a collection of Ten¬ 
derers of a model called a Sequence. Other 
Tenderers for this modeler include the Dots 
view (see Figure 3) and the HBars view (see 
Figure 11) from before. 

Figure 27 shows the repertoire for a sim¬ 
plified version of the Sequence model. 
(The version of the Sticks view in the first 
part of this article has entries in its reper¬ 
toire for showing comparisons, specially 
designated elements, and so on. However, 
the basic ideas are the same as in the sim¬ 
plified repertoire shown in this figure.) 
Figure 28 shows part of the adapter that 
enables sorting algorithms, such as Quick¬ 
sort from Figure 22, to be used with the 
Sequence views, such as the Sticks view. 
The parts of the adapter not shown include 
entry points to handle initialization, termi¬ 
nation, the Swap output event, and the 
PickKey correlate message. 

Because the abstract model generated by 
these output events is essentially the same 
as the abstract model described by the 
Sequence repertoire in Figure 27, it is not 
surprising that the adapter is quite simple. 
However, note that by using an adapter, 
the algorithms, input generators, and 
views can all be coded using conventions 
each finds most suitable without being 
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Message 

Formal Parms 

Description 

module Adapter.Sort2Seq; 

Which Value 

x, y: Integer 
var elt: Integer 
var va1: Reid 

If an element of the sequence were drawn at 
the specified screen coordinates, which 
element would it be and what would be its 

procedure 

Adapter. Sort2Seq. Update. NewKey 
(k, v : Integer ); 

begin 

UpdateMsg .SetName(k, 

Chr(Ord(‘ *’) + k - 1)); 

UpdateMsg.SetValue(k, Real(v)) 

SetName 

SetValue 

i: Integer 
name: String 

v: Real 

The ith element of the sequence has the 
specified label. 

The value of the ith element of the sequence 
is set to the specified value, a real number 
between 0 and 1. 

SwapElts 

i, j: Integer 

Exchange the values and labels of the ith 
and jth elements. 



Figure 27. Repertoire of messages used by the Sticks view (and all other views using 
the Sequence model). Entries above the dotted line are correlate messages, and 
those below the dotted line are update messages. It is assumed that all elements of 
the sequence will be defined using either SetName or SetValue before any SwapElts 
occur. 


Figure 28. Adapter allowing the Sticks 
view (and all other views using the 
Sequence model) to be used with sorting 
algorithms. 


module Views.Seq; 
var { the Sequence model} 

va Is : array [1.. MaxiV] of Real; 
names : array [1.. MaxN] of String; 
numEIts : Integer-, 

procedure Modeler.Seq.StartRun; 
var i : Integer ; 
begin 

numEIts := 0; 

for i := 1 to MaxN do 

begin vals[i] := 0.0; names[i] end 

procedure Modeler.Seq.Update.SetName(i : Integer, 
name : String ); 


names[i] := name 
end; 

procedure Modeler.Seq. Update.Set Value(i : Integer; v : Reid); 
begin 

if numEIts < i then numEIts := i; 
valsji] := v 

procedure Modeler.Seq. Update.SwapElts(i,j : Integer ); 
var tmpVal: Real; tmpName : String; 

tmpVal := vais[i]; va/s[i] := vaJs[/]; vais[/] := tmpVed; 

tmpName := names[i]; names[i] := names[/]; names[/] := tmpName 

end; 

tenderers based on the Sequence model 


begin 

if numEIts < i then numEIts := i; end. 


Figure 29. Implementation of the Sequence modeler. The Tenderers that use this model, such as the Sticks view shown in Fig¬ 
ure 30, are compiled within the scope of the Views.Seq module. 


influenced by any of the components with 
which they will eventually interact. 

Implementing a view. Consider now 
how the Sticks view is actually imple¬ 
mented. The Sequence modeler is shown 
in Figure 29 and the Tenderer in Figure 30. 

The data structures comprising the 


model are an array of floating-point num¬ 
bers representing the value of each ele¬ 
ment, an array of strings representing the 
labels of each element, and an integer, 
numEIts, indicating how many elements 
have been defined thus far. The data struc¬ 
tures are initialized in the StartRun proce¬ 
dure and maintained in a straighforward 


manner based on the three update mes¬ 
sages. Once the Nth element is defined 
using either the SetName or SetValue 
event, Tenderers based on the Sequence 
model assume that elements 1 through N 
are valid and should be displayed. 

The Tenderer does not need any data 
structures of its own, because the layout of 
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the array is quite regular and computed 
easily by setting the appropriate window- 
to-viewport mapping in the graphics 
package. 

In response to the update messages Set- 
Name and Set Value, the Tenderer displays 
the current element unless it is the last one 
defined. In that case, it erases the window, 
repositions all elements, and finally dis¬ 
plays all elements. In response to the 
update message SwapElts, the Tenderer 
draws sticks corresponding to the current 
values of the swapped elements. However, 
before a stick is drawn at position k, say, 
the Tenderer erases the old stick that was 
there. Actually, because the Tenderer has 
no way to know the old value or name of 
the £th element, it just erases the tallest 
possible stick that could have been there. 

Logical zooming into the Sticks view is 
facilitated by the graphics package. The 
procedure DrawAllSticks sets a window 
into the world coordinate system for the 
graphics package, based on the number of 
elements defined so far and the minimum 
and maximum values an element can have. 
The functions GPx and GPy convert their 
arguments from world coordinates into 
device coordinates, taking into account the 
user’s zooming and panning. Thus, the 
west, south, east, and north screen coor¬ 
dinates of the stick for the k element would 
be GPx(k - 1), GPy(minVal), GPx(k), 
GPy(vals[kJ), respectively. When the rou¬ 
tine DrawStick draws a stick, it then 
checks if the stick is sufficiently wide 
(larger than 20 pixels) to also display a 
label. If so, a rectangle in the top part of 
the stick is erased and an appropriate label 
is displayed. 


Related systems 

The Balsa-I model of annotating 
algorithms and splitting the code main¬ 
taining the graphical displays from the 
code comprising the algorithm has led to 
a number of noteworthy algorithm anima¬ 
tion systems by other researchers that I 
alluded to earlier. London and Duisberg 2 
denoted interesting events as Smalltalk 
messages and exploited Smalltalk’s model- 
view-controller mechanisms to automati¬ 
cally notify all views whenever an interest¬ 
ing event occurred. Bentley and 
Kernighan 3 developed a suite of Unix 
tools for animating algorithms. Their sys¬ 
tem captured a stream of interesting 
events, denoted as output statements in a 
certain format, from an algorithm and 


procedure Renderer.Seq.Refresh(); 

begin DrawAllSticks-, end; 
function Renderer .Seq. Correlate. Which Value 

(x,y : Integer ; var elt : Integer; var val: Real) : Boolean; 

{GPxMap, GPyMap convert screen coordinates into world coordinates} 
elt := 1 + TRUNC(GPxMap(x)); 
val := GPyMap(y); 

return true 
end; 

procedure Renderer .Seq. Update.SetName(i : Integer; name : String); 

begin if i = numElts then DrawAllSticks else DrawStick(i); end; 
procedure Renderer.Seq. Update.SetValue(i : Integer ; v : Real); 

begin if i = numElts then DrawAllSticks else DrawStick(i); end; 
procedure Renderer.Seq.Sticks.Update.SwapElts(i,j : Integer); 
begin DrawStick(i); DrawStick(j); end; 

const minVal = 0.0; max Val := 1.0; 
procedure DrawAllSticks; 

{GPwindow, DrawRect, EraseRect arguments: west, south, east, north} 
GPwindow(0.0, minVal, numElts, max Val); 

EraseRect(GPx(0.0), GPy(minVal), GPx(FLOAT(numEJts)), GPy(maxVal)); 
for l := 1 to numElts do 
DrawStick(i); 

procedure DrawStick(i : Integer); 
const border = 3; 
var east, west, yp : Integer; 

west := GPx(FLOAT(i - 1)); 
east := GPx(FLOAT(i )); 

EraseRect(west, GPy (minVal), east, GPy(maxVal)); 

DrawRect(west, GPy(minVal), east, GPy(vais[i])); 
if east — west > 20 then 
begin 

yp := GPy(vaJs[i] - .lx maxVal ); 

EraseRect(west + border, yp - border, east - border, GPy(vals[i ]) - border)); 

DrawCenteredString( (west + east)/2,yp,names[i]); 

end; 


Figure 30. Implementation of the Sticks view renderer. These routines are internal 
to module Views.Seq shown in Figure 29. Consequently, they can access the global 
variables defined there that comprise the Sequence model. 


piped them to a program that converted 
them into graphic primitives. Another pro¬ 
gram either displayed the graphic primi¬ 
tives on the screen or generated typesetting 
commands to include them in documents. 
Both of these approaches have concen¬ 
trated on simplifying the process of con¬ 
structing animations and on the algorithm 
animation system itself, but at the cost of 


limited functionality in how a user can 
interactively explore the animations. 

Recent research in algorithm animation 
has concentrated on declarative methods 
of specifying the relationship between 
interesting events in an algorithm and 
events that drive a view. In Animus, 5 
Duisberg investigated using temporal con¬ 
straints for specifying animations; his sub- 
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sequent work 6 explored constructing 
animations by gesturing. Hyrskykari and 
Raiha 7 are currently investigating how to 
interactively specify the association 
between a program event and a graphical 
action from a predefined collection. These 
innovative approaches do not, however, 
address how users actually use the ani¬ 
mations. 

T he Balsa-11 models for users inter¬ 
acting with animated algorithms 
and for programmers creating 
such animations, and their implementa¬ 
tion in the prototype system, seem com¬ 
plete and functional. Thus far, I have 
devoted considerable attention to the user 
interface for users, but have not addressed 
the user interface for programmers as 
thoroughly. I hope to pursue a number of 
directions to simplify the programmer’s 
task. 

For example, I foresee a large payoff in 
automatically incorporating those displays 
that can be automated. Although many 
displays—especially those that show pro¬ 
gram operations or incremental 
updates—cannot be automated, many 
others can. Part of this research would 
include a data structure browser and a 
graphical editor for defining what generic 
displays of data structures should look 
like. 

Another approach is to allow the user to 
interactively specify which views and input 
generators he or she would like to use from 
the entire library. Currently, the user is 
restricted to using only those views and 
input generators that the programmer spe¬ 
cifically identified to Balsa-II as usable 
with a specific algorithm. Achieving this 
goal will require a more formal under¬ 
standing and description of the com¬ 
ponents. 

Another area to pursue is the use of par¬ 
allelism, both to explore fundamental par¬ 
allel algorithms and to improve the 
Balsa-II implementation. The Balsa-II 
design is well-suited to parallelism: We can 
assign each algorithm and each program¬ 
mer module (that is, algorithm, input 
generator, adapter, modeler, and Ten¬ 
derer) a thread of control. Much of the 
propagation and computation relating to 
events and messages can be done in paral¬ 
lel by the components. For users, parallel¬ 
ism would allow views to be updated in 
parallel at each output event, rather than 
sequentially. 

Clearly, these are but a few of the topics 
that need to be addressed. Interactive algo¬ 
rithm animation environments have 


opened the door for a new style of explor¬ 
ing programs. We now must make it eas¬ 
ier to enter those doors. □ 
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Modeling Multicomputer 
Systems with PARET 

Kathleen M. Nichols and John T. Edmark 
AT&T Bell Laboratories 


P arallel computing has become a 
reality in both commercial and 
research machines. Two of the 
most difficult problems in the design and 
analysis of such systems are handling their 
complexity and developing intuition about 
the parallel environment. Visual tools can 
provide the means for solving both of these 
problems. 

The Parallel Architecture Research and 
Evaluation Tool is one such tool—a soft¬ 
ware package that provides a multicom¬ 
puter system laboratory for studying the 
interaction of algorithms and architec¬ 
tures; the effects of varying physical 
resources on system performance; and 
alternate mapping, scheduling, and rout¬ 
ing strategies, both static and dynamic. To 
handle the complexity of the problem and 
explore performance questions, PARET 
provides an interactive and animated envi¬ 
ronment in which the user exercises mul¬ 
ticomputer models. PARET runs on Sun 
workstations, employing color graphics, 
mouse input, and pop-up menus to control 
and display a simulation engine. It pro¬ 
vides both runtime and summary statistics 
from the simulation. 

Multicomputers are nonshared memory 
multiprocessors of the multiple- 
instruction stream, multiple-data stream 
(MIMD) class—complex systems compris- 
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PARET provides an 
interactive and 
animated environment 
for the design 
and study of 
multicomputers as 
systems, rather than 
as isolated components. 


ing hardware and software. A systems 
architecture approach to multicomputing 
includes the machine architecture, target 
user programs, operating system features, 
if any, and interprocessor communica¬ 
tions primitives. For this approach to be 
effective, we need a model of multicom¬ 
puters that uses abstraction of system com¬ 
ponents to manage complexity while 
capturing salient features. A tool based on 
this abstract model must assist the user in 
understanding and managing the interrela¬ 
tionships of the target system without 
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overwhelming the user with detail. Finally, 
to evaluate multicomputers under our 
model, we have to answer the question: 
How do we measure performance? 

PARET is based on a model that is uni¬ 
form across all the subsystems of a paral¬ 
lel machine and designed for a natural 
graphical representation. A simulation 
with graphical interaction allows the user 
to control and observe the model, and aids 
in the development of intuition about par¬ 
allel systems. We have chosen behavioral 
simulation rather than detailed emulation. 
PARET depicts in graph form the data 
dependence primitives that characterize 
the interactions of the tasks, modules, 
objects, or “schedulable units” of a par¬ 
allel computer. It uses them to model user 
programs, and operating system and hard¬ 
ware primitives. A discrete event-driven 
simulator with simulation entities based on 
the model objects interacts with a graphi¬ 
cal front end. We can monitor runtime 
measures of system objects to provide an 
overall evaluation. 

To develop new policies for static or 
dynamic mapping, scheduling, or routing, 
users can start with the most straightfor¬ 
ward implementation of the policy and 
interactively tune and monitor the system. 
A user selects subsystems to observe, and 
may create and store flow graphs as well 

39 










Subsystem model ^ 

graphs _' 



Summary statistics~~^^^ 

"3T 51 

Simulator engine~^^ 


Figure 1. PARET overview. 


as access a graph library. Summary statis¬ 
tics gathered by the simulator are dumped 
to a file upon request. PARET consists of 
an interactive graphical front end, a simu¬ 
lator back end, and a library of input files 
as shown in Figure 1. 

The study of 

multicomputing 

systems 

We can characterize multicomputer per¬ 
formance by the total execution time of a 
particular program or set of programs 
(benchmarks), the amount of useful com¬ 
puting for each processor in the system 
(utilization), the number of retransmitted 
messages between processors (reliability), 
the ability of the interprocessor intercon¬ 
nection to handle message volume 
(throughput), the transmission speed of 
the interconnection (average delay), and 
the number of routing steps a typical mes¬ 
sage takes (hop count). All of these are use¬ 
ful in studying particular subsystems, 
while only benchmarks also measure the 
general performance of a specific mul¬ 
ticomputer. However, these specific mea¬ 
sures are not appropriate because we focus 
on comparatively evaluating multicom¬ 
puter systems and subsystems, matching 
algorithms and architectures, and develop¬ 
ing intuition about parallel systems. 
Reviewing past work (detailed in the sec¬ 
tion “Previous and related work”) was 
important in deciding the appropriate level 
of abstraction for a systems architecture 
approach. 


Unlike the vector supercomputer world, 
little work of a general nature exists on the 
comparative performance evaluation of 
multiprocessor systems. A supercomputer 
benchmark program is run through 
optimizing and vectorizing compilers and 
executed on the target machine. In con¬ 
trast, porting parallel benchmarks 
between machines requires the time and 
effort of a programmer. The complexity 
of benchmarks depends on the difficulty 
of porting between machines. Although an 
exact measure of the execution time of the 
benchmark program can be obtained, the 
skill of the programmer is not quantifi¬ 
able. Consequently, the meaning of 
observed performance differences is 
unclear. Work with existing parallel 
machines has shown that performance 
greatly depends on the choice of the algo¬ 
rithm and how well it has been parallel¬ 
ized, partitioned, and mapped to the target 
architecture. Further, benchmarking 
requires building hardware and writing a 
compiler. 

Hardware measurement points have 
been largely neglected in current 
implementations of parallel machines. We 
did not consider such multicomputer 
evaluation measurements for PARET for 
three main reasons: 

(1) Retrofitting existing machines with 
probe points is a questionable endeavor, 
since test points in different machines may 
not yield the same measure of per¬ 
formance. 

(2) Multicomputers are composed of 
interacting subsystems, so taking hard¬ 
ware and software measurements can 


cause changes in a multicomputer’s per¬ 
formance (the “probe effect”). 

(3) Systems architects cannot build each 
implementation in order to study it. 

A hardware implementation is appropri¬ 
ate when a machine must meet certain 
fixed specifications; it is crucial when new 
technologies or methodologies must be 
explored. An evaluation tool should build 
on what has been learned from these 
implementations to provide an environ¬ 
ment that invites further study and in 
which new ideas may be tested before 
implementation. Although the lessons 
learned in implementing multicomputers 
have been valuable, the time and expense 
factors dictate that this approach be used 
sparingly. 

Projects geared to specific target 
machines often use emulation tools. 
Detailed emulations require a code-level 
simulation of all the software and emula¬ 
tion of low-level hardware functions. 
Emulators are complex programs and 
require a considerable investment of pro¬ 
gramming and CPU time. Further, a spe¬ 
cific architecture is emulated; adding new 
architectures for comparison is difficult or 
impossible. Although emulators provide 
the most accurate results short of building 
the hardware, they are not appropriate for 
comparing a large number of alternative 
implementations. 

Simulation reduces both cost and 
accuracy compared with emulation. Its 
two major uses have been in general code¬ 
level simulators with simple architecture 
models used by programmers and algo¬ 
rithm designers, and in network simulators 
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Table 1. Approaches to evaluation of multicomputers. 


Approach 

Accuracy 

Complexity 

Flexibility 

Benchmarks 

Good 

Low/Mod 

Low 

Hardware 

Exact 

High 

None 

Emulation 

Good 

High 

Low 

Simulation 

Moderate 

Moderate 

High 

Analytical 

Low/Mod 

High 

High 


for the study of efficient interconnections. 
Programmers can use code-level simula¬ 
tors to develop parallel programs in a com¬ 
mon language, as well as to help 
themselves “think in parallel.” However, 
the effect of a specific architecture on the 
performance of these programs is unpre¬ 
dictable. 

Networks are simulated under random- 
input processes and evaluated on measures 
such as length and number of paths, 
diameter of the network, and utilization of 
links. This approach is useful for evaluat¬ 
ing the effects of changing static resources 
within the networks, but problematical in 
matching an interconnection to a particu¬ 
lar algorithm or program. For instance, 
metrics such as the hop count, or path 
length, of an average message are not prac¬ 
tical for comparative evaluation of mul¬ 
ticomputers, where the cost of packetizing 
and depacketizing messages is large com¬ 
pared to the cost of an additional hop on 
the path. Further, the effects of dynamic 
policies and fluctuations in interprocessor 
traffic are not measured. Thus, charac¬ 
terizing an architecture by these measures 
may predict nothing about the perfor¬ 
mance of a particular program on the 
architecture. Multiprocessor simulators 
are beginning to include the effects of both 
architecture and program. 

Analytical methods have been used for 
parallel systems. The system is modeled 
under the particular constraints of the ana¬ 
lytical method used, so the model can be 
solved by available computer methods. 
These methods are useful for high-level 
modeling of systems about which little is 
known, as well as for modeling small sub¬ 
systems. However, complex systems 
require complex models. Petri nets and 
their derivatives have been used success¬ 
fully for analysis of concurrent systems, 
particularly in computer configurations 
with shared resources, and for the analy¬ 
sis of communication protocols. Com¬ 
plexity is high; a petri net for a simple 
communications protocol between two 
processes typically requires about eight 
places and eight transitions. 1 

Queuing network models and Markov 
chains use a probability distribution to 
represent the software. Traditional com¬ 
puter communications networks have 
been effectively analyzed under these 
models, which can also compare the effec¬ 
tiveness of various interconnection net¬ 
work components, but important func¬ 
tions such as flow control are often 
neglected or oversimplified, and most 
complex queueing models have not been 


solved. Further, these models may miti¬ 
gate the effects of limited buffer sizes and 
the “bursty” nature of real parallel 
programs. 

These approaches are summarized in 
Table 1. Each approach is listed along with 
rough assessments of accuracy (how well 
the actual implementation is represented), 
complexity (the amount of time and detail 
of the approach), and flexibility (how easy 
it is to change or extend it to other systems 
for comparative evaluation). 

Previous and related 
work 

A number of other projects have taken 
on, at least in part, the problem of model¬ 
ing parallel systems. These projects have 
advanced the body of knowledge on mul¬ 
ticomputers and evaluation tools, and the 
PARET project has benefited from them 
both in constructing the tool and in choos¬ 
ing the target level of abstraction. Previ¬ 
ous work has largely centered on 
programming environments and tools for 
programmers rather than tools for system 
architects. 

One example is PIE, a Programming 
and Instrumentation Environment for 
parallel processing. It is specific to a par¬ 
ticular shared memory system, but its 
designers expect it to be translatable to 
other such systems. 2 PIE provides an ani¬ 
mated graphical representation of pro¬ 
gram objects and their relationships. 

Another example that is primarily a 
programmers’ tool is Simon 3,4 and its 
spin-offs. It is an event-based simulator 
that models the parallel execution of a pro¬ 
gram written in the C language; intercon¬ 
nection network models must be written 
by the user. The original environment is 
not user-friendly, and Simon becomes 
quite slow when large or complex net¬ 
works and programs are simulated. Work 
is underway on both a user-friendly inter¬ 


face and a new version of the tool. 

Two tools that take a systems architec¬ 
ture approach are the B-Hive project at 
North Carolina State University and the 
Poker project. B-Hive measures static 
properties of interconnections to select the 
best candidate topologies. 5 To select the 
best architecture for a particular applica¬ 
tion and a simulation of the execution per¬ 
formed, the directed flow graphs 
representing parallel software are algorith¬ 
mically allocated to undirected graphs 
representing the interconnection. The soft¬ 
ware graphs are constrained to be acyclic 
and each processor runs only one subtask, 
represented as one node of the directed 
flow graph. Simulation results are in sum¬ 
mary form, consisting mainly of execution 
times, average utilizations, and average 
path measures. Given these measures, a 
user selects the best architecture for the 
application, an important function in a 
system architecture approach. PARET is 
intended to provide a more flexible envi¬ 
ronment for this approach. It permits a 
wider range of graph types, and animation 
gives dynamic feedback on the architec¬ 
ture selections. 

The Poker system was originally 
planned to emulate a very specific archi¬ 
tecture, the Configurable Highly Parallel 
Computer, 6 although it has been extended 
to the Cosmic Cube. 7 Poker presents an 
integrated environment and allows the 
user to control various levels of the target 
architecture’s system. Separate windows 
allow the user to focus on different mul¬ 
ticomputer functions such as setting the 
switches to create a particular interconnec¬ 
tion, assigning processes to processors, 
and writing the code for a particular pro¬ 
cess. Although Poker provides an excellent 
view of the multicomputer, new architec¬ 
tures are not easily added to it. 

Visually, the tool closest to PARET is 
the Performance Analysis Workstation 
(PAW) for queuing networks, 8 which 
permits users to design a network using a 
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graphical editor and presents simulation 
results visually. The network is animated 
during the simulation, and the user can 
control simulation parameters. PAW has 
been useful and popular, and its visuals 
assist the user in managing complex sys¬ 
tems. This style of interaction should be 
effective for multicomputer systems as 
well. 

PARET provides a flexible, but easy-to- 
use, tool through its graphical user inter¬ 
face. Algorithms and architectures have 
graphical representations drawn from 
files, or that may be created using the built- 
in graphics editor. The user may edit any 
graph displayed by PARET and save the 
changes in an output file. These graphs are 
animated to show each event during simu¬ 
lation, which is controlled from a panel 
displayed on the screen. Runtime statistics 
are presented in animated graphical dis¬ 
plays, pop-up menus, and user-selected 
meters (discussed in the section “PARET 
user interface”). Summary statistics- 
averages over the entire simulation—are 
dumped to a file at the normal termination 
of each simulation. 

PARET reduces the overhead of a code¬ 
level simulation by modeling algorithms 
and architectures as communicating 
directed flow graphs with a set of attrib¬ 
utes for each node and another set for each 
connecting arc. Nodes represent sections 
of higher-level code, such as subroutines 
or functional blocks, while arcs show 
paths of data and control flow. This model 
provides a natural representation for mul¬ 
ticomputer subsystems. Although non- 
shared memory, MIMD parallel systems, 
and multicomputers are targeted, other 
parallel computer models should be pos¬ 
sible. Depicting parallel programs as 
directed flow graphs has become common 
in parallel programming, particularly 
when a data flow programming paradigm 
is used. 5,9 

A PARET software model is similar to 
a data-flow machine program, but each 
node is an execution model of a portion of 
the modeled program. The size of the com¬ 
putation performed by each node is 
medium- or large-grain, that is, a subrou¬ 
tine or functional block of a high-level lan¬ 
guage. The node execution model may be 
as simple as a fixed delay representing the 
execution time of modeled software. 
Nodes may also consist of C or C + + 
instructions, but instruction-level delays 
must be computed by the modeler. 

In architecture models, the nodes may 
be interpreted as finite-state machines per¬ 
forming the functions of either hardware 


or low-level software; such as packetizing, 
flow control, selection of input links for 
servicing, and selection of output links for 
message routing. Arcs represent logical or 
physical paths for data or control informa¬ 
tion and may have capacities, buffers, and 
delays associated with them. PARET pro¬ 
vides runtime interaction with any graph 
whose connectivity and execution infor¬ 
mation can be specified in the PARET 
format. 

A unified model for 

multicomputing 

systems 

A specific multicomputer model is con¬ 
structed of one or more subsystems. The 
present design includes three subsystems: 
user software, system functions, and inter¬ 
connection. The user software represents 
the parallel application program. The sys¬ 
tem functions are those each processor 
must execute that are either transparent to 
the user program or called as library rou¬ 
tines. The interconnection models the 
movement of messages through the mul¬ 
ticomputer. A particular architecture is 
specified by an interconnection and the 
system functions required for passing 
messages. 

Subsystems share the same model—a 
directed flow graph, not necessarily acy¬ 
clic, where nodes represent units of action 
and are connected by arcs for both data 
and control flow. These objects are used 
to model each subsystem: 

• Nodes are primitive units of compu¬ 
tation or action in PARET. 

• Arcs connect the nodes to show con¬ 
trol or data dependency. 

• Elements represent physical entities 
on which nodes can be scheduled for exe¬ 
cution. 

• Tokens are units of data and control 
flow. 

• Buffers provide storage of tokens. 

• Threads are nondisplayed objects 
used to connect the buffers of different 
subsystems when necessary. 

Nodes are represented graphically by 
closed polygons. A node model consists of 
three policies that may be varied to imple¬ 
ment a wide spectrum of node models: 

(1) Input policy: enable execution on 
some condition of node inputs (for exam¬ 
ple, AND policy: at least one token at each 
input arc buffer). 

(2) Execution policy: take action when 
node execution is enabled (for example, 


charge the host element X time units and 
produce one input token at a randomly 
selected node output). 

(3) Output policy: disable execution on 
some condition of node outputs (for exam¬ 
ple, disable node when all outputs are full). 

Arcs connect nodes and are depicted as 
lines with or without buffers. They may 
represent a physical path, such as a wire, 
or a logical path, such as access to a shared 
memory location or a channel between two 
processes on different processors. Ele¬ 
ments do not appear directly in the flow 
graphs, but are represented by the nodes 
that run on them. An element may have 
nodes in more than one subsystem, for 
example, a multicomputer where commu¬ 
nications functions and computations are 
performed by the same processor. A phys¬ 
ical multicomputer is a network of pro¬ 
cessing elements (PEs), switching elements 
(SEs), and communication elements 
(CEs). 

Control and information are modeled 
by tokens. A single token may represent a 
32-byte data message, a 32-bit data word, 
or a signal such as “buffer full.” Tokens 
are represented by solid rectangles within 
buffers. Buffers of a specified token 
capacity may be placed on links or at 
nodes, and they may be subdivided into 
portions for the source and destination of 
an arc, as well as a ghost section for tokens 
not in the currently displayed graph. 
Threads provide a path for tokens between 
subsystems, often from a ghost buffer. 
Consider a channel between processors, 
with a token moving in its logical arc 
between process nodes. The token may 
follow a thread from a ghost buffer in the 
user program graph to a buffer in an inter¬ 
connection network subsystem graph. The 
token must traverse the latter graph before 
it can be returned to the destination end of 
the original arc in the user program graph. 

Figure 2 shows the general structure of 
a model consisting of three subsystems. 
Data and control paths between the sub¬ 
systems are provided by threads, but the 
subsystems also communicate through the 
sharing of elements. Note that user- 
program flow-graph nodes run only on 
PEs, while system-function nodes may run 
on coprocessor CEs, and interconnection 
functions may be performed by switching 
devices as well as PEs and CEs. For exam¬ 
ple, the only elements in a hypercube are 
PEs that must be shared by nodes in all 
flow graphs, while in a multicomputer 
with communication coprocessors and a 
self-routing interconnection, PEs may run 
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Figure 2. Relationship of subsystems. 


only user-software nodes, CEs may run 
only interprocessor-communication 
nodes, and SEs may run only the message¬ 
routing and flow-control nodes. 

For performance evaluation, statistics 
may be collected on all of the above dur¬ 
ing simulation of this model. The gather¬ 
ing of aggregate statistics does not differ 
from the facilities of other simulators, but 
the runtime visual display lets us observe 
the instantaneous value of statistics and 
use it as feedback when model parameters 
are changed interactively. For example, 
aggregate statistics are collected for the 
average execution time of each node, the 
average occupancy of each buffer, the 
average transit time of a token, and the 
amount of time an element spends idle. 
Nodes can be observed executing, blocked, 
or idle, and the causes can be explored. 
Buffers can be seen as full, empty, or 
merely occupied, and additional queries 
can provide information about the tokens 
in a particular buffer. The progression of 
tokens through a graph or even between 
graphs can be monitored. An additional 
facility can observe the instantaneous 
activity of individual elements. 

PARET user interface 

The use of directed flow graphs to rep¬ 
resent all subsystems of the multicomputer 
presents a consistent modeling environ¬ 


ment for users. PARET uses a single high- 
level user interface to maintain a consistent 
work environment. Visual output is 
through a multiwindow, bitmapped, 
color-graphics, CRT screen, and user 
interaction is mouse- and menu-driven. 
The mouse is used for pointing, obtaining 
multilevel pop-up menus, and selecting 
from the menus. The keyboard is used for 
textual information required by some of 
the menu functions. 

Upon entering PARET, a user requests 
a window for each subsystem that will be 
displayed. Note that subsystems may be 
present in PARET without being dis¬ 
played. Specifically, a programmer can 
observe the effects of a bus-based inter¬ 
connection on a software model without 
displaying the bus model. 

A PARET window has three functional 
areas: the display, the meters, and the con¬ 
trol panel. The display contains the graph 
of one subsystem, laid out according to file 
specifications or visual manipulation, or 
by an algorithm built into PARET. The 
meters are time-changing plots of activity 
of a specific element during simulation. 
The control panel allows the user to pilot 
the simulation and modify global simula¬ 
tion parameters. Controls start and stop 
simulation, change the real-time speed of 
the simulation, and set freezes, or break¬ 
points. Users may select nodes and buffers 
in the display, particular meters, or certain 
control panel items with the mouse, invok¬ 


ing pop-up menus where attributes of the 
selected objects may be viewed and 
altered. 

Figure 3 shows the screen during a simu¬ 
lation. The upper left region is the display 
of a software subsystem graph. The pop¬ 
up display menu is used to read and write 
flow-graph files and set up the window for 
simulation. Nodes assigned to execute on 
the same PE have the same color. In Fig¬ 
ure 3, tokens flow from top to bottom, 
through arcs with buffers set to a capacity 
of three tokens. When produced by a 
source node, green tokens are deposited in 
buffers, where they remain until consumed 
by a destination node when it fires (is acti¬ 
vated). A full buffer turns red to alert the 
user. The white rectangles, halos , indicate 
nodes currently executing on their assigned 
element. In Figure 3, node 46 is selected 
and its pop-up menu, with a snapshot of 
node information, has been invoked. 
Menus may be moved with the mouse or 
removed by selecting “hide.” 

Like the nodes, each meter is color- 
coded to the PE it monitors. The meter is 
a strip chart that rolls to the left, monitor¬ 
ing CPU activity on its PE for the past 500 
simulator time units. For the model in Fig¬ 
ure 3, the plot is high while a node is 
executed by the PE; a low plot value indi¬ 
cates an idle PE. When a PE begins to exe¬ 
cute a new node, its label is annotated on 
the chart. Note in Figure 3 that the meter 
of PE 2 has been selected and its pop-up 
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Figure 3. PARET session showing user software model. 



Figure 4. PARET session showing reticles and viewports. 


menu is shown. 

We can freeze the simulation by activat¬ 
ing the freeze button on the control panel, 
or we can stop at specific future times or 
events by presetting freeze points. Two 
chronographs give the simulation time; 
one shows the time of the most recent 
event, and the other—a simulation 
clock—presents a continuous indication of 
time. The user can change the proportion¬ 
ality of simulation clock time to real time 
by moving the velocity slider with the 
mouse. The far-left setting calls for a “sin¬ 
gle event ” mode, and the far-right setting 
causes the simulation to go into “warp 
speed,” where the screen is not updated, 
except for the chronographs. The user can 
also set an “idle break” to freeze the simu¬ 
lation whenever a single PE is idle for this 
preset time. 

For simulating large graphs, the display 
area is divided into several viewports as 
shown in Figure 4. The upper left viewport 
displays the entire graph. The two rectan¬ 
gular outlines within this viewport cor¬ 
respond to the two viewports on the upper 
right and the lower left. The rectangles, 
called reticles, allow the user to focus on 
an area of interest in the graph. The reti¬ 
cle in the upper right viewport corresponds 
to the lower right viewport. Moving or 
resizing the reticles changes the level of 
object detail displayed in each viewport. 
Any changes made in one viewport will 
appear in the others. Mouse selection is 
supported in all viewports. The reticles in 
the main window may be overlapped. 
More recently, a key viewport has been 
added so that the main viewport can also 
be moved and resized. 

An effective multicomputer laboratory 
tool requires flexibility in user interaction, 
but the control mechanisms must be easy 
to learn. The mouse-driven input and 
colorful animated graphics allow a user to 
learn PARET without a complex instruc¬ 
tion manual. Flexibility is accomplished by 
permitting all actions that can’t com¬ 
promise the simulation. For example, 
velocity can be changed and buffer size is 
upwardly adjustable. Also, node, PE, and 
buffer menus are selectable during warp 
speed. A decrease in buffer size, though, 
is impermissible, since loss of tokens may 
result; the capacity slider will return to its 
original position if the user attempts this. 

The structure of the PARET program is 
illustrated in Figure 5. The three boxes rep¬ 
resent program subsections. The file 
reader and writer converts the file lan¬ 
guage into PARET objects (in C + +) and 
vice versa. The simulation engine can 
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access and update these objects, alert the j 
display routines to events that may have I 
changed visual information, and dump 
aggregate statistics to a file. PARET forms 
displays based on the file information, 
provides utilities for building graphs 
visually, and can pass this information to 
be written to a file. It also updates or quer¬ 
ies the object base in response to visually 
entered commands, and passes control 
information (for example, start or freeze) 
to the simulation. 

Modeling 
multicomputer 
subsystems with 
PARET 

We will present two PARET models to 
illustrate the modeling process. The first 
is a user program model for a parallel- 
circuit simulation program. A PARET 
model was made to help answer perfor¬ 
mance questions regarding CEMU, a 
MOS timing simulator that uses a macro 
data-flow paradigm. 10 The second is a 
model of an ICN currently being imple¬ 
mented. 11 The model was created for 
observation of blocking and possible hot 
spots under artificially generated traffic 
loads. 

In CEMU, a circuit is partitioned into 
regions consisting of small numbers of 


Figure 5. PARET program structure. 


interconnected transistors. The regions in 
Figure 6 are enclosed within the blue 
borders. Regions are simulated for one 
basic time step whenever all external inputs 
to the region have a voltage value present. 


When a region is simulated, the oldest volt¬ 
age value at each input is consumed, new 
voltage values for the region are com¬ 
puted, and a voltage value is produced for 
each output. Regions have computation 


a b 



Figure 6. Circuit partitioning in CEMU. 
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Figure 7. Node blocking causes—4 X 4 multiplier: (a) simulation results; 
(b) hypercube results. 


times that vary widely both between differ¬ 
ent regions and between different time- 
step simulations of the same region. 

The circuit may be represented as a 
graph, with a node for each region and 
connecting arcs that correspond to the 
electrical connections crossing partition 
boundaries. Voltage values are passed 
between nodes along the interconnecting 


arcs and may accumulate in fixed-size 
buffers, called queues, on each arc. Nodes 
are blocked from execution if one of their 
output queues is full or one of their input 
queues is empty. 

There were conflicting ideas and evi¬ 
dence about the effect of queue size on 
program performance. Although CEMU 
executes faster with larger queues, it was 


71 speculated that increased execution speed 
S might come from improvements in the 
handling of the costly interprocessor com¬ 
munications functions or from a more 
efficient execution of the underlying pro¬ 
gram graph. 12 Using PARET, a simula¬ 
tion of the parallel program’s execution 
with zero cost communications and a ran¬ 
dom distribution for/Ww)) was examined. 
This model requires only a processing 
element. 

A PARET model of CEMU can be con¬ 
structed from the flow graph and a node 
model that approximately represents 
region execution. The node model is 

(1) Input policy: enable execution when 
at least one token is in the buffer on each 
input arc. 

(2) Execution model: consume one 
token from the buffer on each input arc, 
hold the PE for a time equal to J\x(n)), and 
at the end of this time, produce one token 
for each output arc. x(n) is a time in simu¬ 
lator units associated with a particular 
node, n, and the function / may either 
return this fixed time or one selected from 
a random distribution with mean x(ri). 

(3) Output policy: disable execution 
when there is at least one full buffer on an 
output arc. 

Figure 3 shows the 58-node software 
model of a 4 x 4 multiplier simulated by 
CEMU. The buffers on the arcs model the 
queues and are all of the same fixed size. 
Since CEMU starts with an initial voltage 
value for each region input, the smallest 
feasible buffer size to avoid deadlock is 
two. During simulation with buffer size 
two, buffers blocked node execution early 
and often, indicated by the red color of full 
buffers. Fewer blocked buffers appeared 
as the buffer size was increased using the 
control panel slider. Using the idle break 
feature, the idles were found to occur less 
frequently as the queue size increased. 

In subsequent simulations comparing 
buffer size, fewer full buffers (correspond¬ 
ing to output-blocked nodes) were 
observed as the buffer size increased from 
two, and some improvement in simulated 
execution time was observed. Both these 
effects seemed to level off as the buffer size 
became very large. 

It appeared that the blocking of nodes 
by full output buffers may be correlated to 
the execution time. To verify this, sum¬ 
mary statistics were collected from the 
simulation of several circuits. The results 
in Figure 7a show that the number of 
nodes found blocked on outputs when a 
PE is idle decreases as buffer size is 
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increased, although the number of nodes 
found blocked on inputs increases. This 
result has been partially validated by statis¬ 
tics gathered from CEMU running on the 
Bell Telephone Laboratories hypercube, 
where high communications overhead has 
an additional impact (see Figure 7b). The 
effect is most dramatic for the buffer size 
range from two to eight. Simulated execu¬ 
tion times flattened out and actual execu¬ 
tion times greatly slowed their rate of 
decrease with buffer size around eight. 

Larger buffers require increased mem¬ 
ory, so a buffer size of around eight 
appears to be efficient and even optimal 
with zero communications costs. At larger 
buffer sizes, and with the high-cost inter¬ 
processor communications of the hyper¬ 
cube, execution time also depends on 
queue size due to the communications and 
flow control scheme used. The experience 
with CEMU shows how visual observation 
can help us spot behavior that can be fur¬ 
ther studied by collecting aggregate simu¬ 
lation statistics and data from the target 
system. 

The second PARET model is a hypercu- 
bic interconnection of high-performance 
switching elements, called HPC clusters, 
which have an equal number of input and 
output links. Each input has an indepen¬ 
dent buffer where packets are held until 
control of the internal bus is achieved. An 
idle bus results in virtual cut-through rout¬ 
ing of packets to the correct output link 
(packets are routed as soon as the header 
is recognized). Flow control is handled by 
the clusters via back pressure; when a des¬ 
tination buffer flags its source cluster, the 
cluster blocks execution in its current state 
until the flag drops. Processors are 
attached to links of each cluster not used 
by the backbone interconnection. 

Figure 8 shows a visual display of the 
model for a cubic interconnection com¬ 
posed of 6 x 6 clusters. The flow graph of 
this system was constructed from three 
node models. One node, given a square 
shape, performs the bus control functions 
of the clusters. It blocks its own execution 
when an attempt is made to route tokens 
to a full buffer. A message-generation 
node, a five-sided polygon, produces mes¬ 
sages of random size (in bytes) at random 
intervals. These are packetized and sent 
into and received from the system by 
round communication nodes with an inter¬ 
nal buffer. Cluster buffers are the rectan¬ 
gles shown on the arcs. 

All functions for this random traffic 
generator have been modeled in the same 
PARET window, but message generation 



Figure 8. PARET session showing a model of the HPC interconnection. 


could be performed by a software flow 
graph, such as the CEMU model. In such 
a case, a thread would connect the arc 
buffers of the CEMU model to the node 
buffers of the communication nodes. The 
message-generation nodes would not be 
used. 

More sophisticated monitoring has been 
introduced for this model. Blocking is an 
important phenomenon in this model, so 
halos turn black when a node is blocked. 
Buffer pop-ups (see Figure 8) show the 
processor source and destination of every 
token by color. SE meters at the top of the 
meter area show the number of bytes wait¬ 
ing for service at each cluster as a function 
of time. PE meters each have two plot 
lines: the percentage of time taken by com¬ 
putation, and the communications time 
percentage added to it. The remaining 
space, if any, is percentage of time idle. 
These values have been exponentially 
weighted and are interpolated whenever 
the discrete event discontinuity in time is 
large. 

Previously, aggregate simulation statis¬ 
tics were used to compare the bus switch¬ 
ing at each cluster to crossbar switching. 
Results were surprisingly close for the two 
approaches for reasonable traffic statis¬ 


tics. This model is being verified, after 
which visual observation will be used to 
gain insight into the instantaneous differ¬ 
ences in the two switching paradigms. In 
addition, PARET will be used to evaluate 
a wider range of traffic patterns through 
the use of program models. 

T he goal of the PARET project is 
the design and study of multicom¬ 
puters as systems, rather than as 
isolated components. The model encapsu¬ 
lates only the salient features of parallel 
software and hardware, and represents 
multicomputer subsystems as directed 
flow graphs. 

PARET is intended to have the flexibil¬ 
ity to serve as a multicomputer laboratory. 
It has a number of methods for measuring 
performance, including visual observa¬ 
tion. Performance evaluation of mul- 
ticomputers is a new and dynamic field, 
and the wide selection of performance 
monitors available in PARET should help 
us answer the question of how best to mea¬ 
sure performance. Some of the facilities of 
PARET may turn out to be more impor¬ 
tant than others, and other features may 
be included later. We are at work on a 
C+ + version of the simulation engine, a 
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more user-friendly graph language file for¬ 
mat, and improved meters and statistics 
gathering. PARET already has proven its 
value in some studies, and more are 
under way.O 
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A Remote Computation 
Facility for a Heterogeneous 
Environment 


Brian N. Bershad and Henry M. Levy 
University of Washington 


H eterogeneous software and 
hardware environments present 
special problems in distributed 
computing. To attack these problems, we 
have developed The Heterogeneous Envi¬ 
ronment for Remote Execution. THERE 
is a general-purpose “metaservice” 
designed to simplify the adaptation of 
non-networked, nonheterogeneous appli¬ 
cations to a distributed heterogeneous 
environment. Existing applications made 
accessible with THERE become heter¬ 
ogeneous network services, and users of 
those services become heterogeneous net¬ 
work clients. 

The basis of THERE is a special- 
purpose programming language tailored 
towards building execution environments 
for application programs (on the server 
side), defining client interfaces to remote 
services (on the client side), and providing 
system-independent communication 
between client and server interfaces. Using 
these resources, we can “ roll in a new sys¬ 
tem type” and have it quickly participate 
in the existing environment, both as a cli¬ 
ent of existing services and as a provider of 
new services. THERE handles general 
remote computation problems, such as file 
transfer, as well as problems specific to 
heterogeneity, such as file naming and 
input and output dependencies. 
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THERE simplifies the 
task of making 
existing resources 
available to remote 
users in a 
heterogeneous 
environment. 


Goals of THERE 

Within the framework of simplifying 
remote access to existing resources, 
THERE has been designed to meet several 
objectives. 

• Service immutability. The creation of 
a remote service from an existing program 
cannot require modification of that pro¬ 
gram. This is because (1) source code for 
some programs may not be available, (2) 
modifying source code greatly increases 

0018-9162/88/0500-0050S01.00© 1988 1EEE 


the complexity of the task, and (3) modi¬ 
fied source code can cause significant con¬ 
sistency problems when new program 
versions are introduced. 

• Transparency. The remote execution 
of a service should appear, as much as pos¬ 
sible, exactly as a local execution; users 
should be shielded from any differences in 
environments. While there may be differ¬ 
ences in response time and failure mode, 
the syntax of the command should be 
independent of the type of system execut¬ 
ing the remote service. 

• Compatibility. Existing services must 
be able to accommodate new client system 
types without change. Similarly, an exist¬ 
ing client must be able to use additional 
implementations of a service on new sys¬ 
tem types without change. 

• Extensibility. The remote computa¬ 
tion system must be able to support a wide 
range of potential services running in 
different environments. Thus, a service or 
client can make only very basic assump¬ 
tions about the capabilities of systems with 
which it communicates. 

We have only concerned ourselves with 
the accessibility of resources that can be 
used in a batch-oriented fashion. 
Although this limits the applicability of 
THERE to a subset of an environment’s 
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total resources, we feel justified in ignor¬ 
ing the problems of interactive applica¬ 
tions. First, batch applications represent 
a large percentage of the types of resources 
users need to access in a heterogeneous 
environment. For example, computational 
resources such as compilers and text for¬ 
matters, and hardware resources such as 
printers and special devices, are all batch 
resources. Second, any solutions address¬ 
ing the problems of batch applications will 
be applicable to interactive ones. Finally, 
batch-style applications present a large 
number of interesting and difficult 
research problems. Attacking the prob¬ 
lems of interactive applications as well 
would have been too ambitious. 

We also excluded the goal of exceptional 
performance of the remote computation 
facility from this project. In general, we 
expect that the majority of time will be 
spent executing the remote application, 
and the amount of time spent in commu¬ 
nication and execution of the remote com¬ 
putation facility will be proportionally 
minor. 

Problems with remote 
computation 

A typical network includes resources of 
several types: computational resources, 
such as high-performance processors; 
input/output resources, such as mass stor¬ 
age or printing facilities; and software 
resources, such as databases and text for¬ 
matters. These resources can be shared 
through remote computation, that is, the 
execution of a program or service on a 
processor other than the one used by the 
client. An important issue in remote com¬ 
putation is the ease with which remote 
resources can be made available to net¬ 
work users. 

Homogeneous environments. In a 

strictly homogeneous environment, sys¬ 
tems enabling remote computation need 
only be concerned with the migration of 
state from the client’s machine to the ser¬ 
vice’s machine and back again. This state 
can be as simple as a network connection 
representing a remote login session, or it 
can be complex, consisting of files, envi¬ 
ronment variables, and operating system 
state. 

Users can gain access to network 
resources in several ways. The most com¬ 
mon scheme is to grant each user an 
account on each system; tools such as 
remote login and network file transfer pro¬ 


grams facilitate this. There are three prob¬ 
lems with this approach. First, providing 
accounts on each system may not be 
acceptable. New accounts require adminis¬ 
trative attention and may allow users to 
access more services than would be avail¬ 
able through a deliberate remote execution 
system. It should be possible to permit a 
user to access a particular service without 
providing general access to the machine on 
which it runs. Second, a user must under¬ 
stand aspects of each system such as its 
operation and command language. Third, 
a user can waste a significant amount of 
time executing remote login and file trans¬ 
fer programs to access remote facilities. 
The execution of these facilities is manual, 
synchronous, and tedious. 

To simplify remote access, many sys¬ 
tems provide tools to aid in remote com¬ 
putation. At the programming level, users 
can build distributed services with tools 
such as remote procedure calls 1 or shared 
memory paradigms. 2 ' 3 At the command 
level, remote system utilities such as Ber¬ 
keley Unix remote file copy and remote 
shell execution simplify distributed file 
access, particularly when used with shell 
scripts. Integrated systems such as Eden, 4 
Locus, 5 The Newcastle Connection, 6 and 
VAXclusters 7 provide transparent access 
to network computing or storage facilities. 
Remote computation systems such as Unix 
Maitre d’, 8 Xerox Summoner, 9 and 
Butler 10 provide environments specifically 
for the construction of network services 
and clients. 

Butler, Maitre d’, and Summoner come 
closest to providing general-purpose 
remote execution facilities. In each case, 
these systems work from a basic model 
consisting of a remote service agent on the 
service’s host and a client agent on the 
user’s host. The user invokes the client 
agent, which invokes the remote service 
agent, which in turn invokes the target 
application. The two agents work together 
to migrate the user’s state from the client 
host to the service host. The client agent 
must send (or the remote service agent 
must request) any files needed by the appli¬ 
cation. 

Finding files may be complicated, par¬ 
ticularly when file names are not explicitly 
specified in the command string known to 
the client agent. For example, some text 
processors maintain auxiliary files describ¬ 
ing the structure of a document. These files 
are read if they exist; otherwise, they are 
created. More troublesome, a service may 
have input requirements that become 
known only at execution time. For this rea¬ 


son, some systems require the user to 
explicitly name all input files, 11 while 
other systems preprocess the user’s input 
files in a search for file inclusion 
directives. 8,12 

Systems such as these suffer from one 
principal problem: Each of the client and 
remote service agents is a completely hand¬ 
written program that must be built using 
compiled, procedural code. For example, 
suppose a user wants a list of users logged 
in on another machine in the network. 
Unix systems have a remote finger com¬ 
mand, but systems on machines such as the 
Xerox Dandelion and Tektronix Pegasus 
do not. However, all of these systems have 
a local program that displays the names of 
active users (call it Users). In order to make 
the local program Users available as a net¬ 
work service from just one of the 
machines, someone must write a service 
agent in the “systems language of choice” 
on that machine (such as Mesa, C, or 
Smalltalk), and write client agents that 
interface users to that program from all cli¬ 
ent machines (again, in some systems lan¬ 
guage). The client agents must interact 
with their users and contact the remote 
machine, where the service agent must 
interact with its operating system to run 
the Users program. Both client and server 
agents must also deal with the mundane 
issues of establishing a communication 
link and following a message protocol. 

While a number of the issues these 
agents must solve are specific to the appli¬ 
cation (such as passing any arguments to 
the Users program), others are generic to 
remote computation. It may be conceptu¬ 
ally possible to reuse much of the generic 
code, but there is no general framework 
for doing so. Furthermore, all of these sys¬ 
tems operate within a homogeneous hard¬ 
ware and software environment. 

Heterogeneous environments. In a het¬ 
erogeneous environment, remote compu¬ 
tation becomes both more desirable and 
more difficult. It" is more desirable 
because, by definition, the network con¬ 
tains systems with a variety of resources 
and capabilities that users would like to 
exploit. However, this variety creates dif¬ 
ficulties. A heterogeneous remote execu¬ 
tion system must accommodate the variety 
of environments, as well as deal with the 
problems that any homogeneous system 
must address. Remote computation in a 
homogeneous environment requires only 
that state be migrated; in a heterogeneous 
environment, it must be migrated and 
translated. 
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One fundamental problem specific to 
heterogeneity involves the naming of 
objects: We cannot assume the existence 
of a global name space. Such structures 
imply a standard for expressing names, but 
standards are not often found in a heter¬ 
ogeneous environment. For example, the 
structure of file names may differ on the 
client and service machines. This differ¬ 
ence may include the syntax of file names 
(that is, the set of legal characters or name 
lengths), the specification of directories, 
and the specification of devices or even 
machines where those files reside. Conven¬ 
tions for naming may be different; com¬ 
piling the program myprog may produce 
a.out on one system and myprog.obj on 
another. 

Heterogeneity even complicates the task 
of describing which service to execute. For 
example, most application programs per¬ 
mit the specification of command line and 
environment options, but the syntax and 
semantics of the options differ among sys¬ 
tems. Optimized compiler output may be 
specified by following the compile com¬ 
mand with “-O,” with “/optimize,” or 
perhaps by selecting a menu item. Some 
systems may specify printers by location, 
others by the host to which they are 
attached. 

In addition to explicitly specified 
options, a program’s execution often 
depends on its environment, that is, con¬ 
textual information provided by the user 
and the operating system, including logi¬ 
cal names or aliases, a default directory, 
a directory search path, and some “invisi¬ 
ble” files used by the service for input and 
output. Each application is likely to rely on 
a different set of environmental variables, 
and these must be communicated between 
the client and service. 

Another problem in a heterogeneous 
environment is the binary translation of 
data as it moves from one architecture to 
another. Data format translation may 
occur on the client side, the service side, or 
both, depending on the approach taken. 
Ideally, the underlying communication 
system should handle data translation in 
a way that is transparent to the remote 
computation system. 

An overview of THERE 

Motivated by the issues in both 
homogeneous and heterogeneous remote 
computation, we designed and built a pro¬ 
totype of THERE. As previously 
described, the primary goal of THERE is 


to simplify the creation of new network 
services based on existing applications. 
THERE accomplishes this by facilitating 
the construction of the client agent, the 
service agent, and the communication path 
between the two. 

Satisfying the goals of service immuta¬ 
bility, transparency, compatibility, and 
extensibility requires a set of general, con¬ 
venient facilities that can be layered on top 
of existing applications, adapting them for 
remote access. THERE provides these 
facilities in the context of the THERE Pro¬ 
gramming Language (TPL). We designed 
the language and its runtime support to 
solve many of the hard problems in build¬ 
ing distributed heterogeneous applications 
(such as naming, communication, loca¬ 
tion, binding, and data transfer). Using 
TPL, the service builder can concentrate 
on the problem at hand, namely, building 
an execution environment in which to per¬ 
form the service. The builder of the client 
agent can concentrate on processing the 
user’s command and providing the needed 
information to the service. Differences in 
environment between the service and the 
client, and the details of their communica¬ 
tion, are hidden by the language. 

Figure 1 shows the basic structure of 
THERE. Both client and service hosts exe¬ 
cute an interpreter agent for TPL. In Fig¬ 
ure 1, the client agent for node a provides 
the communication path to four available 
heterogeneous network services: progA, 
progB, progC, and progD. For each user 
request, the client agent interprets a TPL 
program specific to the requested service. 
This client TPL program parses the user’s 
command line, contacts the appropriate 
service agent, and supplies any needed 
information to that service. 

Similarly, the service agent takes 
requests from client agents for services 
available on the service agent’s node. For 
example, in Figure 1, node ft exports two 
services: progA and progB. For each spe¬ 
cific service request, the service agent reads 
and interprets the TPL program for that 
service. This service TPL program is 
responsible for importing information 
from the client, requesting the transfer of 
needed files, establishing the appropriate 
execution environment, executing the ser¬ 
vice, and returning any results. 

The client and service agents are nearly 
identical programs, with the exception of 
certain system-local functions (such as 
opening files, executing programs, and 
creating processes) and their knowledge of 
the roles they play. Of course, they may 
have different implementations on differ¬ 


ent systems, but the language interpreted 
by both client and service agents is the 
same (TPL). 

Building THERE 
applications 

Building a THERE client agent is a 
different (and simpler) task than porting 
the THERE interpreter to a new system 
type. The structure of THERE recognizes 
five independent roles in the construction 
and use of remote services. The five roles 

(1) The user. The user invokes a remote 
service by typing a command to the local 
system. The user is not required to under¬ 
stand anything about the structure of 
THERE, and may even be unaware that 
the service being invoked is remote. 

(2) The applications programmer. The 
applications programmer builds an appli¬ 
cation, typically for users of a single sys¬ 
tem. The applications programmer is 
required to build a “useful” program and 
is not concerned with remote program 
access by heterogeneous clients. 

(3) The exporter. The exporter makes a 
service program available to network 
users. The exporter must understand the 
needs and behavior of the program to be 
exported and the local environment in 
which it runs; it needs no information 
about clients. The exporter programs in 
TPL. 

(4) The importer. The importer makes 
a remote application available to local 
users. The importer needs to understand 
the requirements of the remote application 
as defined by the exporter; that is, the 
interface to the exporter’s TPL program. 
The importer programs in TPL. 

(5) The systems programmer. The sys¬ 
tems programmer provides the underlying 
structure on which the others depend. He 
implements a TPL interpreter on a new 
system type, making it possible for 
importers and exporters to build specific 
client and service agents on that system. 

The systems programmer clearly has the 
most difficult role. The user has the easi¬ 
est role, and the importer’s and exporter’s 
roles lie somewhere between the two. 
However, the skills of the systems pro¬ 
grammer are required only when a new 
system type is introduced. An exporter is 
needed whenever a programmer creates 
something worth exporting, and an 
importer is needed when someone on a 
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Figure 1. System structure. 


given system wishes to benefit from an 
exporter’s efforts. 

To make a new service available, the 
exporter must first decide (1) what infor¬ 
mation is needed from the client, (2) what 
processing the service is willing to do itself, 
(3) what environment will be needed for 
execution, and (4) what data will be 
returned to the client. Based on these deci¬ 
sions, the exporter writes a TPL program, 
which is an executable description of the 
service requirements. The TPL program 
completely defines the interface between 
the service and the client, that is, the infor¬ 
mation to be exchanged between the two, 
the steps needed to process that informa¬ 
tion, and the steps required to create an 
appropriate environment in which to exe¬ 
cute the desired service. Because the service 
environment is constructed in a system- 
specific manner, a different service-side 
TPL program must usually be written for 
each system type on which a given service 
runs. Similarly, a different client TPL pro¬ 
gram exists on each type of system that can 
access a service. 

When a user issues a remote computa¬ 
tion request, the client agent chooses a par¬ 
ticular client TPL program, which has 
been written by the importer to satisfy the 


requirements of the exporter’s TPL pro¬ 
gram. The client TPL program processes 
the user’s command line, gathers environ¬ 
mental information, defines input/output 
relationships, and contacts the service. By 
examining the specifications of a service’s 
TPL program, the importer can see the 
functions provided by the service and how 
those functions rely on information 
provided by the client TPL program. Any 
difference between the client’s needs and 
the service’s abilities is made up with cli¬ 
ent pre- and postprocessing. For example, 
a client might want the output of a service 
to be pretty-printed into a special window 
on the client’s workstation. The importer 
specifies this in the TPL program as a post¬ 
processing phase, rather then requiring 
that the exporter anticipate (and somehow 
support) all types of display devices and 
formatting modes. 

The structure of THERE respects the 
independence of the five roles by giving 
each player a specific task, the difficulty 
of which is inversely related to the fre¬ 
quency with which it must be accom¬ 
plished. Since there is no limit on the 
number of users, nor the frequency with 
which they invoke a remote application, 
THERE requires no work by the user. The 


same is true for the programmer whose 
work becomes a heterogeneous network 
service. Service building and access is the 
complete responsibility of the exporter and 
importer, who write the service and client 
TPL programs shown in Figure 1. 

THERE Programming 
Language 

As described in the previous section, 
building a remote service from an existing 
application or resource requires construc¬ 
tion of several new components on the cli¬ 
ent and server systems. The crucial goal 
was to simplify the tasks of the importer 
and exporter, who make a resource 
remotely available by providing these com¬ 
ponents. Our approach was to use a pro¬ 
gramming language tailored to the needs 
of the importer and exporter, in which they 
could easily express the needs of remote 
computation. 

TPL is the result of several design and 
implementation choices. The first choice 
was between a declarative and imperative 
language. A declarative language was ini¬ 
tially considered in which, for example, 
the exporter could simply list the require- 
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Table 1. Client and server action sequence. 


Client 

Service 

Command line processing 
Environment inspection 
Preprocessing 

Synchronous remote invocation 

Environment creation (data-retrieval) 
Preprocessing 

Execution of program(s) 
Postprocessing 

Return results 

Postprocessing 



— 


/* Simple TPL interface to the line printer program 
LPRprogram = "/usr/ucb/lpr"; 

PrinterName = "-Plpl"; /* 

for (arg in TPLArgs) { /* 

switch (arg) { 

case " -P.*": 

PrinterName = arg; 
break; 
case : 

NumCopies = arg; 
break; 

case " - J": /* & is concatenation operator 

JobName = arg & next arg; 
break; 
case ".: 

files = files & arg; 
break; 

} 

} 


/* must be a filename 
/* concat with files 


7 

default printer is lpl 
parse arguments 


7 

7 


if (NumCopies) /* 7 

options = NumCopies; /* Build command line */ 

if (JobName) /* from arguments */ 

options = options & JobName; /* */ 

/• 7 


command = LPRprogram & options & files; /* Concatenate command7 
/ * Execute the command */ 

status = localExec(LPRoutput = nil,command); 

/* results in LPRoutput */ 


/* Check for errors */ 

if (status) /* Can’t run program */ 

printString("Can’t execute ", command," , status); 
if (LPRoutput) /* Can’t print, error */ 

printString(" Printer error: ", LPRoutput); 
exit("done"); /* Leave quietly */ 


Figure 2. Simple TPL interface to the line printer program. 


ments of the computation. However, an 
imperative approach better suited the 
many special conditions that must be han¬ 
dled at runtime on both the client and 
server. 

Second was the rather straightforward 
choice between a compiled and interpreted 
language. Performance of the TPL pro¬ 
gram was not an issue, since most time is 
spent actually executing the remote appli¬ 
cation. Thus, we took an interpreted 
approach for ease of debugging and port¬ 
ability. 

Finally, TPL could have been imple¬ 
mented as a preprocessor or extension to 
an existing shell-script or high-level lan¬ 
guage. In any case, TPL would have to be 
ported to every system that wished to be a 
THERE server or client machine. We 
chose to invent a simple specialized lan¬ 
guage that would be easier to port than 
most existing languages and could best be 
tailored to our particular needs and the 
needs of the exporter and importer. 

TPL is a high-level language allowing 
the importer and exporter to jointly 
express the behavior and requirements of 
a remote service. We designed the lan¬ 
guage to be easy to learn and use. The 
“feel” of the language is meant to be 
familiar to anyone who has programmed 
in C or Pascal. It is block structured with 
variables, assignments, conditionals, 
switches, and loops. We avoided the temp¬ 
tation to be novel or complex in our lan¬ 
guage design. TPL is not meant to be a 
general-purpose programming language. 
It need only be complete with respect to its 
intended use: building heterogeneous 
services. 

The client and service TPL programs 
work together to define a service in terms 
of control, communication, and transla¬ 
tion. First, the TPL programs control a 
service by describing the steps required to 
either access or provide that service. 
Access is defined by the client program, 
provision by the service program. Second, 
a TPL program indicates how, when, and 
what it intends to communicate to its peer. 
Shared variables, I/O directives, and file 
transfer typify the uses of the communica¬ 
tion facility. Finally, translations allow the 
agents to map between heterogeneous 
environments. The agents ensure that the 
translations are resolved correctly, allow¬ 
ing the importer and exporter to code their 
TPL programs without concern for their 
counterpart’s system type. 

Control. The client program and service 
program control the sequence of actions 
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during the execution of a remote service. 
Table 1 shows this sequence of actions, 
with time proceeding from top to bottom. 

TPL has mechanisms specially designed 
to facilitate the types of actions shown in 
Table 1. The language is heavily biased 
towards textual manipulation. The basic 
data type is the string. Strings can be 
grouped into sequences, and sequences can 
contain other sequences. Strings can be 
interpreted as literals or regular expres¬ 
sions. Operators search, replace, compare, 
extract, and create new string expressions. 
These operators can be applied to objects 
internal to a TPL program (such as vari¬ 
ables, constants, and sequences), or to 
external objects such as files. TPL pro¬ 
grams handle textual pre- and postprocess¬ 
ing (such as, search a file for instances of 
the word foo and replace it with the word 
bar) this way. 

The TPL interpreter also provides a 
suite of built-in functions to remove sys¬ 
tem dependencies from TPL programs, 
and to handle tasks that would be formi¬ 
dable from within the language itself. The 
implementation of these functions may be 
different on different host architectures, 
but the abstractions are the same across all 
systems (as with most high-level lan¬ 
guages). In addition to the built-in func¬ 
tions, each implementation of the 
interpreter may provide certain functions 
on a per-system basis. 

One aspect of TPL’s control facilities is 
its interface to the local environment, that 
is, the environment in which the TPL pro¬ 
gram itself is executing. TPL functions 
check for the existence of files, import 
environment parameters, and execute pro¬ 
grams on the local operating system. The 
last category is primarily intended to give 
the service writer the hooks needed to exe¬ 
cute programs that comprise the exported 
service. The client program might use one 
of these functions to ask a system program 
for an available service host, to pre- or 
postprocess a service request, or to log 
some information to a file. For example, 
the TPL programmer calls 

status=localExec(results, COMMAND) 

where COMMAND is a TPL variable 
whose value specifies the command to be 
executed. The localExec passes its argu¬ 
ment to the local operating system execu¬ 
tive, and the command is run. The return 
value (here assigned to status) will be null 
if the command can be executed normally; 
otherwise, it will contain the error message 
given by the operating system. If the first 


parameter to localExec is a non-null 
sequence, then the output from the com¬ 
mand is written to the client’s console. If 
the first parameter is a variable referring 
to a null sequence, the output is placed in 
a sequence to which the variable then 
refers. TPL programs can thus execute 
programs and process their results, or sim¬ 
ply write the results to the console. 

Figure 2 shows a TPL program demon¬ 
strating integration with its local 
environment—Unix in this case. The pro¬ 
gram parses the user’s command line and 
invokes the standard line-printer utility. 
The command-line arguments are auto¬ 
matically available in the TPL variable 
TPLArgs. The first few lines of the pro¬ 
gram declare the name of the line-printer 
program and the default printer to be used. 
The “for” loop traverses the argument 
list, switching on each of the arguments, 
and building a list of files that should be 
printed in the last arm of the switch. The 
“&” operator concatenates sequences 
(both “files” and “arg” are sequences). 
The last part of the program executes the 
printer program and prints the results 
from LPRoutput if it is non-null. 
Although this example hardly constitutes 
a heterogeneous network service, it serves 
as the basis for building such a service in 
the subsequent discussion. 

Communication. There are essentially 
four categories of communication in any 
remote computation session. First, in the 
remote invocation, the client sends a 
“please-start” message to the service. Sec¬ 
ond, there must be some exchange of 
information both at the beginning and at 
the end of the computation. This exchange 
might be very simple, such as the name of 
the command to be executed and a final 
result status, or it might be more compli¬ 
cated, perhaps consisting of an arbitrary 
sequence of runtime options and compli¬ 
cated error messages. Third, in bulk data 
transfer, files must be transferred from the 
client to the service; any resulting files 
must then be transferred back to the client. 
Finally, there might be interaction with the 
end user responsible for instantiating the 
computation. Existing homogeneous 
remote computation systems tend to deal 
only with the first three categories; few 
deal with user interaction. 

THERE addresses each of these com¬ 
munication needs by presenting them as 
simple abstractions to the TPL program¬ 
mer. The following subsections discuss 
how these abstractions are actually used 
from within TPL programs. 


Remote invocation. The client TPL pro¬ 
gram causes the invocation of a remote 
THERE service by issuing the 

status = 

remoteExec(results = nil, HOST, 
SERVICE_NAME); 

function call. This function invokes the 
service agent at the host named by the TPL 
variable HOST, and asks it to locate and 
execute the service program named 
SERVICE-NAME. The remoteExec 
blocks the client TPL program until the 
service terminates, and status reflects the 
outcome of the call. Some typical values 
for status are “service succeeds,” “no 
such host, ’ ’ “no such service, ’ ’ and “ser¬ 
vice refuses request.” If status indicates an 
error, subsequent handling is the respon¬ 
sibility of the client TPL program. The 
semantics of the first parameter are the 
same as with a localExec (assign output 
into a null sequence reference, otherwise 
write output to the console). The console 
of a TPL program running on the service 
host is the client’s. 

It is important to note that the binding 
of client to service need not be done until 
the client program actually executes. That 
is, the value of the TPL variable HOST in 
the previous example can be defined at 
runtime. This feature makes THERE suit¬ 
able for use in load-sharing systems where 
the sharing policy can be cleanly separated 
from the mechanism, which is provided by 
THERE. Assuming the existence on the 
client of a program findHost that will 
interrogate a load-information database 
and return the name of a lightly loaded 
host, a TPL code segment bringing 
together load-sharing policy and mecha¬ 
nism would look like 


/* get a service host */ 
status = 

localExec(HOST = nil, 

"findHost"); 

/* output of findHost in HOST */ 
/* run service, results to console */ 
status = 

remoteExec(" TO-CONSOLE", 
HOST, SERVICE-NAME); 


Information exchange. Although the 
client and service TPL programs execute 
in different address spaces on different 
machines, TPL allows them to share var- 
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-- 

/* Service program for printer */ 

shared PrinterName; 


shared ResultMessage; 


shared FilesToPrint; 


switch (PrinterName) 

{ 

case "First Floor": 

PrinterName = " lgp"; 


break; 

case "Second Floor": 

PrinterName = "ps2"; 


break; 

case " Third Floor": 

PrinterName = " ps3"; 


break; 

case " Fourth Floor": 

PrinterName = "ps4"; 


break; 

} 

. . . Build "command" from client’s arguments . . . 

. . . Determine the files t 

o print. . . 

. . . Retrieve those files from the client. . . 

status = localExec(LPRoutput = nil,command); 


/* results in LPRoutput */ 

. . . Check errors . . . 



Figure 3. Service program similar to Figure 1. 


iables. This is the primary way two TPL 
programs exchange information. A 
sequence of shared declarations at the 
beginning of each service TPL program 
specifies TPL variables to be shared with 
the client. A similar sequence of shared 
declarations heads the associated client’s 
program, indicating which variables are 
actually exported by the client. Those var¬ 
iables declared as shared on both the cli¬ 
ent and service TPL programs are then 
actually shared between the two programs. 
Thus, there must be consensus as to which 
variables are to be shared; all other vari¬ 
ables are private. 

Because execution of the service TPL 
program is synchronous with the client, no 
synchronization on the shared variables is 
required. In essence, a remoteExec is simi¬ 
lar to a remote procedure call, with shared 
variables being analogous to the argu¬ 
ments of a remote procedure call. One can 
think of the shared variables as call-by¬ 
value-result parameters to the remote exe¬ 
cution. 

The service program dictates the proper 
interpretation for the values of shared var¬ 
iables. The client program sets the values 
prior to a remote invocation according to 
the expectations of the service program. It 


reinterprets them afterwards according to 
their use remotely. For example, the pro¬ 
gram in Figure 3 transforms the simple 
TPL printer program into a network ser¬ 
vice running under TFIERE. The program 
says the name of the default printer should 
be found in the shared TPL variable Prin- 
terName. The value of this variable is 
expected to be one of the locations given 
by the cases of the switch. The program 
translates the generic printer name into a 
host-specific one by executing the appro¬ 
priate line-printer command and returning 
the results in the shared variable Result- 
Message. 

Seeing this, the client TPL programmer 
must ensure that the two shared variables 
are dealt with appropriately (see Figure 4). 
Since “TO_CONSOLE” is a non-null 
sequence (as is any string), output from the 
remote service is written directly onto the 
client’s console. 

The style in which the service side TPL 
program is written, particularly with 
respect to the expected values of the shared 
variables, is conceptually crucial to 
THERE’s support for heterogeneity. A 
service TPL program should define a 
system-independent interface for client 
TPL programs. The service TPL program¬ 


mer must understand that different clients 
will need to be produced on different sys¬ 
tem types, and that the details of compu¬ 
tation (such as the local printer names in 
Figure 3) on the server should be invisible 
to the clients. Furthermore, other service 
TPL programs may be written to support 
the same service on different system types. 
These programs will need to export exactly 
the same shared variable interface, even 
though their local systems will require 
different local interfaces. For example, a 
particular text formatter may run on 
different system types. At runtime, a cli¬ 
ent may choose one or the other based on 
availability or loading; which service TPL 
implementation actually executes should 
be invisible to the client TPL program. 

Interactive I/O. While shared variables 
allow communication between cooperat¬ 
ing TPL programs, simple I/O routines 
permit direct communication between the 
user and the TPL program. 

inputstring = read(); 

printString(" Just read ", inputstring) 

Both the client and service TPL programs 
can use these routines to read directly from 
or write directly to the user’s console, with 
reads blocking until the user enters a 
string. The input can then be assigned to 
a TPL variable. 

File transfer. Interactive I/O and shared 
variables work well for exchanging small 
amounts of information between TPL 
programs, but they are impractical for 
moving large data objects such as files. 
TPL instead provides two functions for 
this purpose: 

getFiles(FILENAMES); 

putFiles(FILENAMES); 

These functions transfer the files in the 
argument sequence FILENAMES 
between the client host and a temporary 
directory on the service. All file transfers 
in THERE occur at the request of the ser¬ 
vice TPL program and are forwarded by 
the service agent to the client agent, 
although the client TPL program still 
remains blocked on its original 
remoteExec call. Figure 5 illustrates the 
control flow between the client’s invoca¬ 
tion and the service’s file transfer requests. 

There are several reasons for making file 
transfer the responsibility of the service. 
Most importantly, the service often must 
know the context motivating the transfer. 
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and it is typically in a better position to 
know which files must actually be trans¬ 
ferred. For example, the service might scan 
the input files looking for directives that 
specify the inclusion of other files. This 
can only be done by preprocessing those 
inputs that are explicit in the remote invo¬ 
cation request (expressed via shared vari¬ 
ables), and searching for inclusion 
directives. Each inclusion may require spe¬ 
cial processing on the service (such as file 
name translation) that goes beyond simply 
retrieving the file. Consequently, even if 
the client were to prescan all inputs and 
move all referenced files to the service, a 
second phase of service preprocessing 
would still be needed. Making the service 
responsible for file transfer eliminates this 
duplication of effort in many cases. In 
addition, there are times when the service 
may choose to cache certain files from a 
client’s machine and only retrieve those 
files that are newer than the cached ver¬ 
sions. Such a policy should certainly be 
transparent to clients. 

It is the responsibility of the client agent 
to satisfy a service’s getFiles requests (pos¬ 
sibly by looking through some default 
search path in the client’s environment). 
The service agent considers failure to com¬ 
pletely retrieve any file a fatal error; it will 
report the offending files and terminate. 
Errors in putFiles are dealt with more 
gently; the client is simply notified and 
processing continues. The motivation 
behind these semantics is simple: An input 
failure is likely to cause serious problems 
with the exported application, whereas an 
output failure only implies that a service 


can’t return all that it has created, and 
allows the user to determine the proper 
action. 

Name translation. As mentioned 
earlier, naming is one of the substantial 
problems in heterogeneous remote compu¬ 


tation. The final function of TPL is to 
define name translations between objects 
referenced on both the client and service 
hosts. These translations permit objects 
that have moved from one host to another 
to be referenced by either host. The trans¬ 
lation mechanisms provided by the lan- 



/* Client program for remote print service */ 
shared PrinterName; 
shared ResultMessage; 
shared FilesToPrint; 

for (arg in TPLArgs) { /* parse client’s command line */ 


switch (arg) 

{ 

case "/lwl": 

PrinterName = " First Floor"; 
break; 

case " /ap2": 

PrinterName = " Second Floor" 
break; 

default: 

PrinterName = "Fourth Floor"; 
break; 


HOST = "june"; 

status = remoteExec("TO_CONSOLE", HOST,"printer.tpl"); 

/* Regular expression compare of shared ResultMessage */ 
if (ResultMessage == ". Tailed. *") 

printStringC Remote job failed because " .ResultMessage," \n"); 

else 

printStringC Remote Succeeds\n"); 


Figure 4. Client program for remote print service. 
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Figure 5. Runtime control flow. 


May 1988 


57 























/ * Program 4 */ 

/* Printservice */ 
shared PrinterName; 
shared ResultMessage; 

shared FilesToPrint; /* the client indicates these */ 

)*' 

* figure out which printer to use and build up 

* partial command line in commandLine 

7 

/*’ 

* Create a filename mapping from the client to the service 

V 

ServiceFilesToPrint = makeLocalNames(FilesToPrint, " TYPE_TEXT"); 

/* 

* Retrieve the files from the client 

7 

getFiles(ServiceFilesToPrint) 

/* 

* Complete the command line with the filenames as they are called 

* on the service host 

7 

commandLine = commandLine & ServiceFilesToPrint; 

/* Execute commandLine with localExec(). . . deal with problems */ 


Figure 6. Service program with file name dependencies. 


guage allow clients and services to 
maintain syntactic and semantic views of 
the objects that are consistent with the 
local environment. The types of objects of 
interest are command-line arguments, 
environmental variables, and files. There 
are three forms of translation with which 
THERE concerns itself: one-way, two- 
way, and two-way dependent. 

One-way translations. One-way trans¬ 
lations were used in Figures 3 and 4 to map 
a printer named on the user’s command 
line or environment (“/lwl”) into a sys¬ 
tem-independent name (“First Floor”), 
and then into a system-dependent name on 
the service (“lgp”). One-way translations 
are simple enough to be negotiated at the 
TPL program level using shared variables 
and the comparison operators. Typically, 
the service TPL program deals with one¬ 
way translations by importing shared var¬ 
iables from the client. The service defines 
the possible values and meanings of the 
variables, and the client must bind one of 


the possible values to its exported vari¬ 
ables. As previously noted, the service 
writer is encouraged to import machine- 
independent values for its shared variables 
and then translate those independent 
values into machine-dependent ones. 

Using intermediate names such as “First 
Floor” and “Second Floor” for 
designators—rather than requiring that 
the client TPL translate from a local name 
to a name appropriate for the service 
environment—allows the client TPL to be 
free of references to the service environ¬ 
ment. Similarly, with intermediate 
representations, the service TPL does not 
have to know about the naming conven¬ 
tions on any of its clients, allowing a sin¬ 
gle service program to be used for all 
clients in the heterogeneous environment. 
In addition, the use of intermediate 
representations in TPL programs allows a 
single client program to utilize instances of 
the same service running on different het¬ 
erogeneous hosts. 


Two-way translations. Two-way trans¬ 
lations are necessary when an object must 
be referenced both locally and remotely. 
They are motivated by the need to trans¬ 
fer files between hosts. All operating sys¬ 
tems do not use the same file-naming 
conventions, so it becomes necessary to 
use file names appropriate to each service 
and its supporting operating system. 

THERE solves this problem through the 
use of a file name typing mechanism. A 
THERE file name type allows the TPL 
agent to create syntactically appropriate 
file names for data files as they are trans¬ 
ferred from one host to another. File name 
types control only the syntax of the file 
names, and are related to the file’s con¬ 
tents only by the conventions or require¬ 
ments of the underlying operating system. 
The agents know about most file name 
types (for example, file name type TEXT 
means “make a unique six-character file 
name using all uppercase letters with the 
extension .TXT”). A file name type has no 
implications for the contents of the file. In 
cases where the contents themselves must 
be typed (such as a file of records of 
floating-point numbers), the client and 
service TPL programs must rely on some 
canonical form for the data and explicitly 
preprocess into and out of that form as the 
file moves from the client to the service 
host. 

An agent’s knowledge about most com¬ 
mon file name types (such as C, Pascal, 
Ada, Scribe, TeX, and troff) comes from 
a sequence of system-type specific rules 
encoded within the agent. The TPL service 
program creates the local names for a list 
of REMOTE_FILES with the call 

/* service */ 

shared ClientFiles; 

ServiceFiles = 

makeLocalNames(CIientFiles, 

TYPE_SELECTOR); 


where TYPE_SELECTOR selects the 
appropriate file name generator within the 
agent’s library functions. This call creates 
an implicit mapping between the names in 
the sequence ClientFiles (imported from 
the client using shared variables) and those 
in ServiceFiles. Any subsequent function 
call involving file transfer can reference 
either ClientFiles or ServiceFiles. The 
function will select the appropriate name 
based on intent and context. 

Figure 6 expands the Printservice exam- 
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fc - -- fa 


Figure 7. Resolving file name dependencies. 


pie in Figures 3 and 4. The call to get- F 
Files(ServiceFilesToPrint) could also be 1 
expressed as getFiles(FilesToPrint). Both 
calls cause a file transfer request to be sent 
from the service agent back to the client 
agent, asking for the appropriate file 
named in the context of the client. Once 
retrieved, the file is stored in the scratch 
directory named according to the transla¬ 
tion indicated via makeLocalNames. Simi¬ 
larly, on a putFiles request, the correct 
mapping from service to client name is 
done transparently to the TPL program¬ 
mer. In both cases, the TPL interpreter 
running on the service will translate 
names, if necessary, before sending the 
request to the client. 

Two-way dependencies. Although the 
makeLocalNames construct creates an 
acceptable name space for one type of 
name translation, it ignores the common 
situation where file names can be depen¬ 
dent on one another. For example, when 
compiling the files a.c and b.c on a Unix 
client host, one expects the files a.o and 
b.o to be created. It is possible that the cli¬ 
ent would interact with a VMS C compiler, 
which expects source files to end with .C 
and generates dependent outputs ending in 
.OBJ. Dissimilar dependency relations, 
coupled with the fact that input file names 
may not be the same on the client as they 
are on the service, led to the creation of 
two-way dependent translations. 

Two-way dependencies allow the agents 
to determine how to correctly remap an 
output file name from the service back to 
the client. For each file maintained on the 
service, there can be five pieces of infor¬ 
mation: 

(1) The name of the file on the client 
<fc): 

CLIENT_INPUT = f c 

(2) The name of the file on the service 
(fs): 

SERVICE_INPUT = f s 

(3) A relation defined by the client 
indicating that f c ' is an output file 
that would arise from the input file 
fc if the equivalent service were run 
locally. This information accompa¬ 
nies the service request from the cli¬ 
ent to the service: 

fc—fc' 

(4) A relation defined on the service 
indicating that/s' is an output file 


that arises from the input file/ s : 
fs —fs' 

(5) The type “T” of the two relations. 
Unlike the file name types used for 
makeLocalNames, there is no 
preset list of dependency types. The 
TPL service program defines the 
dependency with some labeled type 
(a string). The TPL client program 
adheres to the same type name when 
expressing the parallel relation: 

TYPE = “T” 

The client exports the dependency infor¬ 
mation necessary to resolve the derived 
output file names generated by the service 
with those expected on the client. Unlike 
shared variables, this information is 
implicitly exported from the client to the 
service; no special TPL directives are 
needed. 

Returning output files is straightfor¬ 
ward (see Figure 7). The service agent 
looks at the name of each output file to be 
returned. Using this name, it searches the 
dependency relations on the service for the 
type of the output file and the service’s ver¬ 
sion of the input file name from which the 
output file was derived. Since the service 
input file name can be translated back to 
the client input file name, and since the 
type of the output file is known, the service 
agent need only examine the dependency 
rules on the client to determine the name 
to be used when returning the output file 
to the client. If no dependency informa¬ 
tion is available to the service, the file is 
returned with the same name as on the ser¬ 
vice’s host. 

All translations are handled automati¬ 


cally by the file transfer functions in a TPL 
program. If only one output file could be 
created from a given input file, then the 
type specifier would not be needed. But, 
since this is not always the case, the type 
field is necessary to select the correct 
input/output relation. 

The noteworthy characteristic of each 
of the three translation mechanisms is that 
the understanding of environments 
required by the client program, service 
program, and both agents is limited to the 
host on which they run. Specific rules for 
mapping names from one host type to 
another are not encoded anywhere in 
either the TPL programs or the agent. 
Instead, only information influencing half 
the translation process is provided by the 
client or service host. The information 
provided by both halves is merged, so that 
complete translation rules can be created 
at runtime. Matching of names to the 
objects they represent is the responsibility 
of the host in which the names are contex¬ 
tually meaningful. This feature allows us 
to integrate new system types into the 
THERE environment without modifica¬ 
tion of existing services. 


Project status 

THERE has been used to build servers 
for printer access, for text formatters (TeX 
and troff), for observing network status, 
and for a remote Ada compiler. The client 
and server agents exist in full form under 
4.2 BSD Unix, and consist of about 9,000 
lines of code written in C + + . Except for 
one small module, the client and server 
agents are source-level identical. Although 
writing the agent is not a trivial effort, it 
only has to be done once per system type. 
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In contrast, our most complex service (the 
remote Ada compiler) required only about 
200 lines of TPL code for each of the cli¬ 
ent and service machines. The majority of 
that code deals with argument parsing and 
error handling. Compare this with the 
roughly 2,500 lines of code required to 
implement a remote Pascal compiler using 
the Maitre d’ system. 8 

Under Unix, THERE runs on all VAX 
hardware, Sun workstations, and IBM RT 
PCs. A THERE client agent has been 
implemented in Mesa on the Xerox Dan¬ 
delion workstation. We are also working 
to complete a THERE port to the Tektro¬ 
nix Pegasus machine running Uniflex, a 
weak derivative of Unix. 

T HERE was intended to simplify 
the task of building and accessing 
services in a heterogeneous dis¬ 
tributed environment. Our experiences in 
building several real applications have 
demonstrated the utility of the system. 
Clients and services can be written without 
regard to the problems of heterogeneity. 
Integrating a new system type into the het¬ 
erogeneous environment requires porting 
only the interpreter. In addition, as a result 
of the system’s structure, THERE has 
proven an effective solution to the prob¬ 
lems of homogeneous remote compu¬ 
tation. □ 


Acknowledgments 

THERE could only exist within the larger 
context of the Heterogeneous Computer Sys¬ 
tems project at the University of Washington, 13 
in which a large number of faculty and students 
are attempting to solve the problems that arise 
when integrating loosely connected collections 


of heterogeneous hardware and software sys¬ 
tems. We would like to thank Andrew Black and 
James Synge in particular for contributing to 
early designs of our remote computation server. 
Other HCS project participants include Kimi 
Gosney, Ed Lazowska, David Notkin, Jan 
Sanislo, Mike Schwartz, Mark Squillante, and 
John Zahorjan. 

This research has been supported by the 
National Science Foundation under Grants No. 
DCR-8420945 and CCR-8611390, by the Xerox 
Corporation University Grants Program, and 
by the Digital Equipment Corporation External 
Research Program. 


References 

1. A.P. Birrell and B.J. Nelson, “Implement¬ 
ing Remote Procedure Calls, "ACM Trans. 
Computer Systems, Jan. 1984, pp. 39-59. 

2. N.CarrieroandD.Gelernter,“TheS/Net’s 
Linda Kernel,” ACM Trans. Computer 
Systems, May 1986, pp. 110-129. 

3. K. Li, Shared Virtual Memory on Loosely 
Coupled Multiprocessors, doctoral disser¬ 
tation, Yale Univ., Sept. 1985. 

4. G.T. Aimes, A.P. Black, and E.D. 
Lazowska, “The Eden System: A Techni¬ 
cal Review,” IEEE Trans. Software 
Engineering, Jan. 1985, pp. 43-58. 

5. B. Walker et al., “The Locus Distributed 
Operating System,” Proc. Ninth ACM 
Symp. Operating Systems Principles, Nov. 
1983, pp. 49-70. 

6. A. Brownbridge, A. Marshall, and A. Ran- 
dell, “The Newcastle Connection or Unixes 
of the World Unite,” Software Practice and 
Experience, Dec. 1982, pp. 1147-1162. 

7. N.P. Kronenberg, H.M. Levy, and W.D. 
Strecker, “VAXclusters: A Closely Cou¬ 
pled Distributed System,” ACM Trans. 
Computer Systems, May 1986, pp. 130-146. 

8. B.N. Bershad, “Load Balancing With 
Maitre d’,” Computer Science Division 
UCB/CSD 86/276, Univ. of Calif., Ber¬ 
keley, Dec. 1985. 

9. R. Hagmann, “Process Server: Sharing 
Processing Power In A Workstation Envi¬ 


Moving? 

PLEASE NOTIFY 

Name (Please Print) 

US 4 WEEKS 

IN ADVANCE 

New Address 


City State/Country Zip 

MAIL TO: 

• This notice of address change will apply to all 

IEEE Service Center 

ATTACH IEEE publications to wnich you subscribe. 

LABEL • i_j s t n ew address above. 

445 Hoes Lane 
Piscataway, NJ 08854 

HERE . |f you have a question about your subscription, 


place label here and clip this form to your letter. 


ronment,” Proc. Sixth IEEE Int’l Conf. 
Distributed Computing Systems, May 1986, 
pp. 260-267. 

10. R. Dannenberg, Resource Sharing in a Net¬ 
work of Persona! Computers, doctoral dis¬ 
sertation, Carnegie Mellon Univ., Dec. 
1982. 

11. K. Hwang et al., “A Unix-Based Local 
Computer Network with Load Balancing, ’ ’ 
Computer, Apr. 1982, pp. 55-65. 

12. J.C. Chung, “Dscribe: A Scribe Server,” 
Tech. Report MIT/LCS/TM-288, Lab. for 
Computer Science, MIT, 1985. 

13. A.P. Blacketal., “InterconnectingHeter¬ 
ogeneous Computer Systems,” Comm. 
ACM, Mar. 1988. 



Brian N. Bershad is a PhD student in the Dept, 
of Computer Science at the University of Wash¬ 
ington, Seattle. His current research interests 
include parallel and distributed systems, pro¬ 
gramming environments, and performance 

Bershad received the BS degree in electrical 
engineering and computer science from the Uni¬ 
versity of California at Berkeley in 1986. 



Henry M. Levy is a research assistant professor 
in the Dept, of Computer Science at the Univer¬ 
sity of Washington, Seattle, and a consulting 
engineer on leave from Digital Equipment Corp. 
His current research interests include distributed 
and parallel operating systems and computer 
architecture. He is the author of Capability- 
Based Computer Systems (Digital Press) and 
coauthor of Computer Programming and 
Architecture: The VAX-11 (Digital Press). 

Levy received the BS degree from Carnegie 
Mellon University in Pittsburgh, Pa., and the 
MS degree from the University of Washington, 
Seattle. 


Readers may write to Henry Levy at the Dept, 
of Computer Science, FR-35, University of 
Washington, Seattle, WA 98195. 


COMPUTER 














A Spiral Model of Software 
Development and 
Enhancement 

Barry W. Boehm, TRW Defense Systems Group 


“Stop the life cycle—I want to get off!” 
“Life-cycle Concept Considered 
Harmful. ” 

“The waterfall model is dead. ” 

“No, it isn’t, but it should be. ” 

T hese statements exemplify the 
current debate about software 
life-cycle process models. The 
topic has recently received a great deal of 
attention. 

The Defense Science Board Task Force 
Report on Military Software' issued in 
1987 highlighted the concern that tradi¬ 
tional software process models were dis¬ 
couraging more effective approaches to 
software development such as prototyping 
and software reuse. The Computer Soci¬ 
ety has sponsored tutorials and workshops 
on software process models that have 
helped clarify many of the issues and 
stimulated advances in the field (see “Fur¬ 
ther reading”). 

The spiral model presented in this arti¬ 
cle is one candidate for improving the soft¬ 
ware process model situation. The major 
distinguishing feature of the spiral model 
is that it creates a risk-driven approach to 
the software process rather than a primar¬ 
ily document-driven or code-driven pro¬ 
cess. It incorporates many of the strengths 
of other models and resolves many of their 
difficulties. 

This article opens with a short descrip¬ 
tion of software process models and the 
issues they address. Subsequent sections 
outline the process steps involved in the 



This evolving risk- 
driven approach 
provides a new 
framework for guiding 
the software process. 


spiral model; illustrate the application of 
the spiral model to a software project, 
using the TRW Software Productivity 
Project as an example; summarize the pri¬ 
mary advantages and implications 
involved in using the spiral model and the 
primary difficulties in using it at its current 
incomplete level of elaboration; and pre¬ 
sent resulting conclusions. 

Background on software 
process models 

The primary functions of a software 
process model are to determine the order 
of the stages involved in software develop¬ 
ment and evolution and to establish the 
transition criteria for progressing from one 
stage to the next. These include completion 


criteria for the current stage plus choice 
criteria and entrance criteria for the next 
stage. Thus, a process model addresses the 
following software project questions: 

(1) What shall we do next? 

(2) How long shall we continue to do it? 

Consequently, a process model differs 

from a software method (often called a 
methodology) in that a method’s primary 
focus is on how to navigate through each 
phase (determining data, control, or 
“uses” hierarchies; partitioning functions; 
allocating requirements) and how to rep¬ 
resent phase products (structure charts; 
stimulus-response threads; state transition 
diagrams). 

Why are software process models 
important? Primarily because they pro¬ 
vide guidance on the order (phases, incre¬ 
ments, prototypes, validation tasks, etc.) 
in which a project should carry out its 
major tasks. Many software projects, as 
the next section shows, have come to grief 
because they pursued their various devel¬ 
opment and evolution phases in the wrong 
order. 

Evolution of process models. Before 
concentrating in depth on the spiral model, 
we should take a look at a number of 
others: the code-and-fix model, the stage- 
wise model and the waterfall model, the 
evolutionary development model, and the 
transform model. 

The code-and-fix model. The basic 
model used in the earliest days of software 
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Figure 1. The waterfall model of the software life cycle. 


development contained two steps: 

(1) Write some code. 

(2) Fix the problems in the code. 
Thus, the order of the steps was to do 

some coding first and to think about the 
requirements, design, test, and main¬ 
tenance later. This model has three pri¬ 


mary difficulties: 

(a) After a number of fixes, the code 
became so poorly structured that subse¬ 
quent fixes were very expensive. This 
underscored the need for a design phase 
prior to coding. 

(b) Frequently, even well-designed soft¬ 


ware was such a poor match to users’ needs 
that it was either rejected outright or 
expensively redeveloped. This made the 
need for a requirements phase prior to 
design evident. 

(c) Code was expensive to fix because of 
poor preparation for testing and modifi- 
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cation. This made it clear that explicit 
recognition of these phases, as well as test- 
and-evolution planning and preparation 
tasks in the early phases, were needed. 

The stagewise and waterfall models. As 
early as 1956, experience on large software 
systems such as the Semi-Automated 
Ground Environment (SAGE) had led to 
the recognition of these problems and to 
the development of a stagewise model 2 to 
address them. This model stipulated that 
software be developed in successive stages 
(operational plan, operational specifica¬ 
tions, coding specifications, coding, 
parameter testing, assembly testing, 
shakedown, system evaluation). 

The waterfall model, 3 illustrated in Fig¬ 
ure 1, was a highly influential 1970 refine¬ 
ment of the stagewise model. It provided 
two primary enhancements to the stage- 
wise model: 

(1) Recognition of the feedback loops 
between stages, and a guideline to 
confine the feedback loops to suc¬ 
cessive stages to minimize the 
expensive rework involved in feed¬ 
back across many stages. 

(2) An initial incorporation of pro¬ 
totyping in the software life cycle, 
via a “build it twice” step running 
in parallel with requirements anal¬ 
ysis and design. 

The waterfall model’s approach helped 
eliminate many difficulties previously 
encountered on software projects. The 
waterfall model has become the basis for 
most software acquisition standards in 
government and industry. Some of its ini¬ 
tial difficulties have been addressed by 
adding extensions to cover incremental 
development, parallel developments, pro¬ 
gram families, accommodation of evolu¬ 
tionary changes, formal software 
development and verification, and stage- 
wise validation and risk analysis. 

However, even with extensive revisions 
and refinements, the waterfall model’s 
basic scheme has encountered some more 
fundamental difficulties, and these have 
led to the formulation of alternative pro¬ 
cess models. 

A primary source of difficulty with the 
waterfall model has been its emphasis on 
fully elaborated documents as completion 
criteria for early requirements and design 
phases. For some classes of software, such 
as compilers or secure operating systems, 
this is the most effective way to proceed. 
However, it does not work well for many 
classes of software, particularly interactive 


The waterfall model 
has become the basis 
for most software 
acquisition standards. 


end-user applications. Document-driven 
standards have pushed many projects to 
write elaborate specifications of poorly 
understood user interfaces and decision- 
support functions, followed by the design 
and development of large quantities of 
unusable code. 

These projects are examples of how 
waterfall-model projects have come to 
grief by pursuing stages in the wrong 
order. Furthermore, in areas supported by 
fourth-generation languages (spreadsheet 
or small business applications), it is clearly 
unnecessary to write elaborate specifica¬ 
tions for one’s application before imple¬ 
menting it. 

The evolutionary development model. 
The above concerns led to the formulation 
of the evolutionary development model, 4 
whose stages consist of expanding incre¬ 
ments of an operational software product, 
with the directions of evolution being 
determined by operational experience. 

The evolutionary development model is 
ideally matched to a fourth-generation 
language application and well matched to 
situations in which users say, “I can’t tell 
you what I want, but I’ll know it when I see 
it.” It gives users a rapid initial operational 
capability and provides a realistic opera¬ 
tional basis .for determining subsequent 
product improvements. 

Nonetheless, evolutionary development 
also has its difficulties. It is generally dif¬ 
ficult to distinguish it from the old code- 
and-fix model, whose spaghetti code and 
lack of planning were the initial motiva¬ 
tion for the waterfall model. It is also 
based on the often-unrealistic assumption 
that the user’s operational system will be 
flexible enough to accommodate 
unplanned evolution paths. This assump¬ 
tion is unjustified in three primary circum¬ 
stances: 

(1) Circumstances in which several 
independently evolved applications must 
subsequently be closely integrated. 

(2) “Information-sclerosis” cases, in 
which temporary work-arounds for soft¬ 
ware deficiencies increasingly solidify into 


unchangeable constraints on evolution. 
The following comment is a typical exam¬ 
ple: “It’s nice that you could change those 
equipment codes to make them more intel¬ 
ligible for us, but the Codes Committee 
just met and established the current codes 
as company standards.” 

(3) Bridging situations, in which the 
new software is incrementally replacing a 
large existing system. If the existing system 
is poorly modularized, it is difficult to pro¬ 
vide a good sequence of “bridges” 
between the old software and the expand¬ 
ing increments of new software. 

Under such conditions, evolutionary 
development projects have come to grief 
by pursuing stages in the wrong order: 
evolving a lot of hard-to-change code 
before addressing long-range architectural 
and usage considerations. 

The transform model. The “spaghetti 
code” difficulties of the evolutionary 
development and code-and-fix models can 
also become a difficulty in various classes 
of waterfall-model applications, in which 
code is optimized for performance and 
becomes increasingly hard to modify. The 
transform model 5 has been proposed as a 
solution to this dilemma. 

The transform model assumes the exis¬ 
tence of a capability to automatically con¬ 
vert a formal specification of a software 
product into a program satisfying the spec¬ 
ification. The steps then prescribed by the 
transform model are 

• a formal specification of the best ini¬ 
tial understanding of the desired 
product; 

• automatic transformation of the 
specification into code; 

• an iterative loop, if necessary, to 
improve the performance of the 
resulting code by giving optimization 
guidance to the transformation 
system; 

• exercise of the resulting product; and 

• an outer iterative loop to adjust the 
specification based on the resulting 
operational experience, and to reder¬ 
ive, reoptimize, and exercise the 
adjusted software product. 

The transform model thus bypasses the 
difficulty of having to modify code that 
has become poorly structured through 
repeated reoptimizations, since the 
modifications are made to the specifica¬ 
tion. It also avoids the extra time and 
expense involved in the intermediate 
design, code, and test activities. 

Still, the transform model has various 
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difficulties. Automatic transformation 
capabilities are only available for small 
products in a few limited areas: spread¬ 
sheets, small fourth-generation language 
applications, and limited computer- 
science domains. The transform model 
also shares some of the difficulties of the 
evolutionary development model, such as 
the assumption that users’ operational sys¬ 
tems will always be flexible enough to sup¬ 
port unplanned evolution paths. 


Additionally, it would face a formidable 
knowledge-base-maintenance problem in 
dealing with the rapidly increasing and 
evolving supply of reusable software com¬ 
ponents and commercial software 
products. (Simply consider the problem of 
tracking the costs, performance, and fea¬ 
tures of all commercial database manage¬ 
ment systems, and automatically choosing 
the best one to implement each new or 
changed specification.) 


The spiral model 

The spiral model of the software process 
(see Figure 2) has been evolving for several 
years, based on experience with various 
refinements of the waterfall model as 
applied to large government software 
projects. As will be discussed, the spiral 
model can accommodate most previous 
models as special cases and further pro- 
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vides guidance as to which combination of 
previous models best fits a given software 
situation. Development of the TRW Soft¬ 
ware Productivity System (TRW-SPS), 
described in the next section, is its most 
complete application to date. 

The radial dimension in Figure 2 
represents the cumulative cost incurred in 
accomplishing the steps to date; the angu¬ 
lar dimension represents the progress 
made in completing each cycle of the spi¬ 
ral. (The model reflects the underlying 
concept that each cycle involves a progres¬ 
sion that addresses the same sequence of 
steps, for each portion of the product and 
for each of its levels of elaboration, from 
an overall concept of operation document 
down to the coding of each individual pro¬ 
gram.) Note that some artistic license has 
been taken with the increasing cumulative 
cost dimension to enhance legibility of the 
steps in Figure 2. 

A typical cycle of the spiral. Each cycle 
of the spiral begins with the identification 
of 

• the objectives of the portion of the 
product being elaborated (perfor¬ 
mance, functionality, ability to 
accommodate change, etc.); 

• the alternative means of implement¬ 
ing this portion of the product (design 
A, design B, reuse, buy, etc.); and 

• the constraints imposed on the appli¬ 
cation of the alternatives (cost, sched¬ 
ule, interface, etc.). 

The next step is to evaluate the alterna¬ 
tives relative to the objectives and con¬ 
straints. Frequently, this process will 
identify areas of uncertainty that are sig¬ 
nificant sources of project risk. If so, the 
next step should involve the formulation 
of a cost-effective strategy for resolving 
the sources of risk. This may involve pro¬ 
totyping, simulation, benchmarking, 
reference checking, administering user 
questionnaires, analytic modeling, or 
combinations of these and other risk- 
resolution techniques. 

Once t he risks are evaluated, the next 
step is determined"5y th e relative remain- 
ing risks. If performance or user-interface 
‘ risks strongly dominate program develop¬ 
ment or internal interface-control risks, 
the next step may be an evolutionary devel¬ 
opment one: a minimal effort to specify 
the overall nature of the product, a plan 
for the next level of prototyping, and the 
development of a more detailed prototype 
to continue to resolve the major risk issues. 

If this prototype is operationally useful 
and robust enough to serve as a low-risk 


base for future product evolution, the sub¬ 
sequent risk-driven steps would be the 
evolving series of evolutionary prototypes 
going toward the right in Figure 2. In this 
case, the option of writing specifications 
would be addressed but not exercised. 
Thus, risk considerations can lead to a 
project implementing only a subset of all 
the potential steps in the model. 

On the other hand, if previous prototyp¬ 
ing efforts have already resolved all of the 
performance or user-interface risks, and 
program development or interface-control 
risks dominate, the next step follows the 
basic waterfall approach (concept of oper¬ 
ation, software requirements, preliminary 
design, etc. in Figure 2), modified as 
appropriate to incorporate incremental 
development. Each level of software spec¬ 
ification in the figure is then followed by 
a validation step and the preparation of 
plans for the succeeding cycle. In this case, 
the options to prototype, simulate, model, 
etc. are addressed but not exercised, lead¬ 
ing to the use of a different subset of steps. 

This risk-driven subsetting of the spiral 
model steps allows the model to accommo¬ 
date any appropriate mixture of a 
specification-oriented, prototype- 
oriented, simulation-oriented, automatic 
transformation-oriented, or other 
approach to software development. In 
such cases, the appropriate mixed strategy 
is chosen by considering the relative mag¬ 
nitude of the program risks and the rela¬ 
tive effectiveness of the various techniques 
in resolving the risks. In a similar way, 
risk-management considerations can 
determine the amount of time and effort 
that should be devoted to such other proj¬ 
ect activities as planning, configuration 
management, quality assurance, formal 
verification, and testing. In particular, 
risk-driven specifications (as discussed in 
the next section) can have varying degrees 
of completeness, formality, and granular¬ 
ity, depending on the relative risks of 
doing too little or too much specification. 

An important feature of the spiral 
model, as with most other models, is that 
each cycle is completed by a review involv¬ 
ing the primary people or organizations 
concerned with the product. This review 
covers all products developed during the 
previous cycle, including the plans for the 
next cycle and the resources required to 
carry them out. The review’s major objec¬ 
tive is to ensure that all concerned parties 
are mutually committed to the approach 
for the next phase. 

The plans for succeeding phases may 
also include a partition of the product into 


increments for successive development or 
components to be developed by individual 
organizations or persons. For the latter 
case, visualize a series of parallel spiral 
cycles, one for each component, adding a 
third dimension to the concept presented 
in Figure 2. For example, separate spirals 
can be evolving for separate software com¬ 
ponents or increments. Thus, the review- 
and-commitment step may range from an 
individual walk-through of the design of 
a single programmer’s component to a 
major requirements review involving 
developer, customer, user, and main¬ 
tenance organizations. 

Initiating and terminating the spiral. 

Four fundamental questions arise in con¬ 
sidering this presentation of the spiral 
model: 

(1) How does the spiral ever get 
started? 

(2) How do you get off the spiral when 
it is appropriate to terminate a proj¬ 
ect early? 

(3) Why does the spiral end so 
abruptly? 

(4) What happens to software enhance¬ 
ment (or maintenance)? 

The answer to these questions involves 
an observation that the spiral model 
applies equally well to development or 
enhancement efforts. In either case, the 
spiral gets started by a hypothesis that a 
particular operational mission (or set of 
missions) could be improved by a software 
effort. The spiral process then involves a 
test of this hypothesis: at any time, if the 
hypothesis fails the test (for example, if 
delays cause a software product to miss its 
market window, or if a superior commer¬ 
cial product becomes available), the spiral 
is terminated. Otherwise, it terminates 
with the installation of new or modified 
software, and the hypothesis is tested by 
observing the effect on the operational 
mission. Usually, experience with the 
operational mission leads to further 
hypotheses about software improvements, 
and a new maintenance spiral is initiated 
to test the hypothesis. Initiation, termina¬ 
tion, and iteration of the tasks and 
products of previous cycles are thus 
implicitly defined in the spiral model 
(although they’re not included in Figure 2 
to simplify its presentation). 

Using the spiral model 

The various rounds and activities 
involved in the spiral model are best under- 
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stood through use of an example. The spi¬ 
ral model was used in the definition and 
development of the TRW Software Pro¬ 
ductivity System (TRW-SPS), an inte¬ 
grated software engineering environ¬ 
ment. 6 The initial mission opportunity 
coincided with a corporate initiative to 
improve productivity in all appropriate 
corporate operations and an initial 
hypothesis that software engineering was 
an attractive area to investigate. This led 
to a small, extra “Round 0” circuit of the 
spiral to determine the feasibility of 
increasing software productivity at a 
reasonable corporate cost. (Very large or 
complex software projects will frequently 
precede the “concept of operation” round 
of the spiral with one or more smaller 
rounds to establish feasibility and to 
reduce the range of alternative solutions 
quickly and inexpensively.) 

Tables 1,2, and 3 summarize the appli¬ 
cation of the spiral model to the first three 
rounds of defining the SPS. The major 
features of each round are subsequently 


discussed and are followed by some exam¬ 
ples from later rounds, such as preliminary 
and detailed design. 

Round 0: Feasibility study. This study 
involved five part-time participants over a 
two- to three-month period. As indicated 
in Table 1, the objectives and constraints 
were expressed at a very high level and in 
qualitative terms like “significantly 
increase,” “at reasonable cost,” etc. 

Some of the alternatives considered, 
primarily those in the ‘ ‘technology” area, 
could lead to development of a software 
product, but the possible attractiveness of 
a number of non-software alternatives in 
the management, personnel, and facilities 
areas could have led to a conclusion not to 
embark on a software development 
activity. 

The primary risk areas involved possi¬ 
ble situations in which the company would 
invest a good deal only to find that 

• resulting productivity gains were not 
significant, or 


• potentially high-leverage improve¬ 
ments were not compatible with some 
aspects of the “TRW culture.” 

The risk-resolution activities under¬ 
taken in Round 0 were primarily surveys 
and analyses, including structured inter¬ 
views of software developers and 
managers, an initial analysis of productiv¬ 
ity leverage factors identified by the con¬ 
structive cost model (Cocomo) 7 ; and an 
analysis of previous projects at TRW 
exhibiting high levels of productivity. 

The risk analysis results indicated that 
significant productivity gains could be 
achieved at a reasonable cost by pursuing 
an integrated set of initiatives in the four 
major areas. However, some candidate 
solutions, such as a software support envi¬ 
ronment based on a single, corporate, 
maxicomputer-based time-sharing system, 
were found to be in conflict with TRW 
constraints requiring support of different 
levels of security-classified projects. Thus, 
even at a very high level of generality of 
objectives and constraints, Round 0 was 
able to answer basic feasibility questions 
and eliminate significant classes of candi¬ 
date solutions. 

The plan for Round 1 involved commit¬ 
ment of 12 man-months compared to the 
two man-months invested in Round 0 
(during these rounds, all participants were 
part-time). Round 1 here corresponded 
fairly well to the initial round of the spiral 
model shown in Figure 2, in that its intent 
was to produce a concept of operation and 
a basic life-cycle plan for implementing 
whatever preferred alternative emerged. 

Round 1: Concept of operations. Table 
2 summarizes Round 1 of the spiral along 
the lines given in Table 1 for Round 0. The 
features of Round 1 compare to those of 
Round 0 as follows: 

• The level of investment was greater 
(12 versus 2 man-months). 

• The objectives and constraints were 
more specific (“double software produc¬ 
tivity in five years at a cost of $10,000 a 
person” versus “significantly increase 
productivity at a reasonable cost”). 

• Additional constraints surfaced, such 
as the preference for TRW products (par¬ 
ticularly, a TRW-developed local area net¬ 
work (LAN) system). 

• The alternatives were more detailed 
(“SREM, PSL/PSA or SADT, as require¬ 
ments tools etc.” versus “tools”; “pri¬ 
vate/shared” terminals, “smart/dumb” 
terminals versus “workstations”). 

• The risk areas identified were more 
specific (“TRW LAN price-performance 


Table 1. Spiral model usage: TRW Software Productivity System, Round 0. 


Objectives 

Significantly increase software productivity 

Constraints 

At reasonable cost 

Within context of TRW culture 
• Government contracts, high tech., people oriented, 
security 

Alternatives 

Management: Project organization, policies, planning, 
control 

Personnel: Staffing, incentives, training 

Technology: Tools, workstations, methods, reuse 
Facilities: Offices, communications 

Risks 

May be no high-leverage improvements 

Improvements may violate constraints 

Risk resolution 

Internal surveys 

Analyze cost model 

Analyze exceptional projects 

Literature search 

Risk resolution results 

Some alternatives infeasible 

• Single time-sharing system: Security 

Mix of alternatives can produce significant gains 

• Factor of two in five years 

Need further study to determine best mix 

Plan for next phase 

Six-person task force for six months 

More extensive surveys and analysis 
• Internal, external, economic 

Develop concept of operation, economic rationale 

Commitment 

Fund next phase 
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within a $10,000-per-person investment 
constraint” versus “improvements may 
violate reasonable-cost constraint”). 

• The risk-resolution activities were 
more extensive (including the benchmark¬ 
ing and analysis of a prototype TRW LAN 
being developed for another project). 

• The result was a fairly specific opera¬ 
tional concept document, involving pri¬ 
vate offices tailored to software work 
patterns and personal terminals connected 
to VAX superminis via the TRW LAN. 
Some choices were specifically deferred to 
the next round, such as the choice of oper¬ 
ating system and specific tools. 

• The life-cycle plan and the plan for the 
next phase involved a partitioning into sep¬ 
arate activities to address management 
improvements, facilities development, and 
development of the first increment of a 
software development environment. 

• The commitment step involved more 
than just an agreement with the plan. It 
committed to apply the environment to an 
upcoming 100-person testbed software 
project and to develop an environment 
focusing on the testbed project’s needs. It 
also specified forming a representative 
steering group to ensure that the separate 
activities were well-coordinated and that 
the environment would not be overly 
optimized around the testbed project. 

Although the plan recommended 
developing a prototype environment, it 
also recommended that the project employ 
requirements specifications and design 
specifications in a risk-driven way. Thus, 
the development of the environment fol¬ 
lowed the succeeding rounds of the spiral 
model. 

Round 2: Top-level requirements spec¬ 
ification. Table 3 shows the corresponding 
steps involved during Round 2 defining the 
software productivity system. Round 2 
decisions and their rationale were covered 
in earlier work 6 ; here, we will summarize 
the considerations dealing with risk 
management and the use of the spiral 
model: 

• The initial risk-identification activities 
during Round 2 showed that several sys¬ 
tem requirements hinged on the decision 
between a host-target system or a fully 
portable tool set and the decision between 
VMS and Unix as the host operating sys¬ 
tem. These requirements included the 
functions needed to provide a user- 
friendly front-end, the operating system to 
be used by the workstations, and the func¬ 
tions necessary to support a host-target 


operation. To keep these requirements in 
synchronization with the others, a special 
minispiral was initiated to address and 
resolve these issues. The resulting review 
led to a commitment to a host-target oper¬ 
ation using Unix on the host system, at a 
point early enough to work the OS- 
dependent requirements in a timely 
fashion. 

• Addressing the risks of mismatches to 
the user-project’s needs and priorities 
resulted in substantial participation of the 
user-project personnel in the requirements 
definition activity. This led to several sig¬ 
nificant redirections of the requirements, 
particularly toward supporting the early 
phases of the software life-cycle into which 
the user project was embarking, such as an 
adaptation of the software requirements 
engineering methodology (SREM) tools 


for requirements specification and 
analysis. 

It is also interesting to note that the form 
of Tables 1,2, and 3 was originally devel¬ 
oped for presentation purposes, but sub¬ 
sequently became a standard “spiral 
model template” used on later projects. 
These templates are useful not only for 
organizing project activities, but also as a 
residual design-rationale record. Design 
rationale information is of paramount 
importance in assessing the potential reus¬ 
ability of software components on future 
projects. Another important point to note 
is that the use of the template was indeed 
uniform across the three cycles, showing 
that the spiral steps can be and were uni¬ 
formly followed at successively detailed 
levels of product definition. 


Table 2. Spiral model usage: TRW Software Productivity System, Round 1. 


Objectives 

Double software productivity in five years 

Constraints 

$10,000 per person investment 

Within context of TRW culture 
• Government contracts, high tech., people oriented, 
security 

Preference for TRW products 

Alternatives 

Office: Private/modular/. . . 

Communication: LAN/star/concentrators/. . . 
Terminals: Private/shared; smart/dumb 

Tools: SREM/PSL-PSA/. . .; PDL/SADT/. . . 

CPU: IBM/DEC/CDC/. . . 

Risks 

May miss high-leverage options 

TRW LAN price/performance 

Workstation cost 

Risk resolution 

Extensive external surveys, visits 

TRW LAN benchmarking 

Workstation price projections 

Risk resolution results 

Operations concept: Private offices, TRW LAN, personal 
terminals, VAX 

Begin with primarily dumb terminals; experiment with 
smart workstations 

Defer operating system, tools selection 

Plan for next phase 

Partition effort into software development environment 
(SDE), facilities, management 

Develop first-cut, prototype SDE 
• Design-to-cost: 15-person team for one year 

Plan for external usage 

Commitment 

Develop prototype SDE 

Commit an upcoming project to use SDE 

Commit the SDE to support the project 

Form representative steering group 
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Succeeding rounds. It will be useful to 
illustrate some examples of how the spiral 
model is used to handle situations arising 
in the preliminary design and detailed 
design of components of the SPS: the 
preliminary design specification for the 
requirements traceability tool (RTT), and 
a detailed design rework or go-back on the 
unit development folder (UDF) tool. 

The RTT preliminary design specifica¬ 
tion. The RTT establishes the traceability 
between itemized software requirements 
specifications, design elements, code ele¬ 
ments, and test cases. It also supports var¬ 
ious associated query, analysis, and report 
generation capabilities. The preliminary 
design specification for the RTT (and most 
of the other SPS tools) looks different 
from the usual preliminary design specifi¬ 
cation, which tends to show a uniform 
level of elaboration of all components of 
the design. Instead, the level of detail of 


the RTT specification is risk-driven. 

In areas involving a high risk if the 
design turned out to be wrong, the design 
was carried down to the detailed design 
level, usually with the aid of rapid pro¬ 
totyping. These areas included working 
out the implications of “undo” options 
and dealing with the effects of control keys 
used to escape from various program 
levels. 

In areas involving a moderate risk if the 
design was wrong, the design was carried 
down to a preliminary-design level. These 
areas included the basic command options 
for the tool and the schemata for the 
requirements traceability database. Here 
again, the ease of rapid prototyping with 
Unix shell scripts supported a good deal of 
user-interface prototyping. 

In areas involving a low risk if the design 
was wrong, very little design elaboration 
was done. These areas included details of 
all the help message options and all the 


report-generation options, once the nature 
of these options was established in some 
example instances. 

A detailed design go-back. The UDF 
tool collects into an electronic “folder” all 
artifacts involved in the development of a 
single-programmer software unit (typi¬ 
cally 500 to 1,000 instructions): unit 
requirements, design, code, test cases, test 
results, and documentation. It also 
includes a management template for track¬ 
ing the programmer’s scheduled and 
actual completion of each artifact. 

An alternative considered during 
detailed design of the UDF tool was reuse 
of portions of the RTT to provide pointers 
to the requirements and preliminary design 
specifications of the unit being developed. 
This turned out to be an extremely attrac¬ 
tive alternative, not only for avoiding 
duplicate software development but also 
for bringing to the surface several issues 
involving many-to-many mappings 
between requirements, design, and code 
that had not been considered in designing 
the UDF tool. These led to a rethinking of 
the UDF tool requirements and prelimi¬ 
nary design, which avoided a great deal of 
code rework that would have been neces¬ 
sary if the detailed design of the UDF tool 
had proceeded in a purely deductive, top- 
down fashion from the original UDF 
requirements specification. The resulting 
go-back led to a significantly different, less 
costly, and more capable UDF tool, incor¬ 
porating the RTT in its “uses-hierarchy.” 

Spiral model features. These two exam¬ 
ples illustrate several features of the spiral 
approach. 

• It fosters the development of specifi¬ 
cations that are not necessarily uniform, 
exhaustive, or formal, in that they defer 
detailed elaboration of low-risk software 
elements and avoid unnecessary breakage 
in their design until the high-risk elements 
of the design are stabilized. 

• It incorporates prototyping as a risk- 
reduction option at any stage of develop¬ 
ment. In fact, prototyping and reuse risk 
analyses were often used in the process of 
going from detailed design into code. 

• It accommodates reworks or go-backs 
to earlier stages as more attractive alterna¬ 
tives are identified or as new risk issues 
need resolution. 

Overall, risk-driven documents, partic¬ 
ularly specifications and plans, are impor¬ 
tant features of the spiral model. Great 
amounts of detail are not necessary unless 
the absence of such detail jeopardizes the 


Table 3. Spiral model usage: TRW Software Productivity System, Round 2. 


Objectives 

User-friendly system 

Integrated software, office-automation tools 

Support all project personnel 

Support all life-cycle phases 

Constraints 

Customer-deliverable SDE => Portability 

Stable, reliable service 

Alternatives 

OS: VMS/AT&T Unix/Berkeley Unix/ISC 

Host-target/fully portable tool set 

Workstations: Zenith/LSI-11/. . . 

Risks 

Mismatch to user-project needs, priorities 

User-unfriendly system 
• 12-language syndrome; experts-only 

Unix performance, support 

Workstation/mainframe compatibility 

Risk resolution 

User-project surveys, requirements participation 

Survey of Unix-using organizations 

Workstation study 

Risk resolution results 

Top-level requirements specification 

Host-target with Unix host 

Unix-based workstations 

Build user-friendly front end for Unix 

Initial focus on tools to support early phases 

Plan for next phase 

Overall development plan 

• for tools: SREM, RTT, PDL, office automation tools 

• for front end: Support tools 

• for LAN: Equipment, facilities 

Commitment 

Proceed with plans 
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project. In some cases, such as with a 
product whose functionality may be deter¬ 
mined by a choice among commercial 
products, a set of weighted evaluation 
criteria for the products may be prefera¬ 
ble to a detailed pre-statement of func¬ 
tional requirements. 

Results. The Software Productivity Sys¬ 
tem developed and supported using the 
spiral model avoided the identified risks 
and achieved most of the system’s objec¬ 
tives. The SPS has grown to include over 
300 tools and over 1,300,000 instructions; 
93 percent of the instructions were reused 
from previous project-developed, TRW- 
developed, or external-software packages. 
Over 25 projects have used all or portions 
of the system. All of the projects fully 
using the system have increased their pro¬ 
ductivity at least 50 percent; indeed, most 
have doubled their productivity (when 
compared with cost-estimation model 
predictions of their productivity using tra¬ 
ditional methods). 

However, one risk area—that projects 
with non-Unix target systems would not 
accept a Unix-based host system—was 
underestimated. Some projects accepted 
the host-target approach, but for various 
reasons (such as customer constraints and 
zero-cost target machines) a good many 
did not. As a result, the system was less 
widely used on TRW projects than 
expected. This and other lessons learned 
have been incorporated into the spiral 
model approach to developing TRW’s 
next-generation software development 
environment. 

Evaluation 

Advantages. The primary advantage of 
the spiral model is that its range of options 
accommodates the good features of exist¬ 
ing software process models, while its risk- 
driven approach avoids many of their dif¬ 
ficulties. In appropriate situations, the spi¬ 
ral model becomes equivalent to one of the 
existing process models. In other situa¬ 
tions, it provides guidance on the best mix 
of existing approaches to a given project; 
for example, its application to the TRW- 
SPS provided a risk-driven mix of specify¬ 
ing, prototyping, and evolutionary devel¬ 
opment. 

The primary conditions under which the 
spiral model becomes equivalent to other 
main process models are summarized as 
follows: 

• If a project has a low risk in such areas 


All of the projects 
fully using the system 
have increased their 
productivity at least 
50 percent. 


as getting the wrong user interface or not 
meeting stringent performance require¬ 
ments, and if it has a high risk in budget 
and schedule predictability and control, 
then these risk considerations drive the spi¬ 
ral model into an equivalence to the water¬ 
fall model. 

• If a software product’s requirements 
are very stable (implying a low risk of 
expensive design and code breakage due to 
requirements changes during develop¬ 
ment), and if the presence of errors in the 
software product constitutes a high risk to 
the mission it serves, then these risk con¬ 
siderations drive the spiral model to resem¬ 
ble the two-leg model of precise 
specification and formal deductive pro¬ 
gram development. 

• If a project has a low risk in such areas 
as losing budget and schedule predictabil¬ 
ity and control, encountering large-system 
integration problems, or coping with 
information sclerosis, and if it has a high 
risk in such areas as getting the wrong user 
interface or user decision support require¬ 
ments, then these risk considerations drive 
the spiral model into an equivalence to the 
evolutionary development model. 

• If automated software generation 
capabilities are available, then the spiral 
model accommodates them either as 
options for rapid prototyping or for appli¬ 
cation of the transform model, depending 
on the risk considerations involved. 

• If the high-risk elements of a project 
involve a mix of the risk items listed above, 
then the spiral approach will reflect an 
appropriate mix of the process models 
above (as exemplified in the TRW-SPS 
application). In doing so, its risk- 
avoidance features will generally avoid the 
difficulties of the other models. 

The spiral model has a number of addi¬ 
tional advantages, summarized as follows: 

It focuses early attention on options 
involving the reuse of existing software. 
The steps involving the identification and 
evaluation of alternatives encourage these 
options. 


It accommodates preparation for life- 
cycle evolution, growth, and changes of 
the software product. The major sources 
of product change are included in the 
product’s objectives, and information¬ 
hiding approaches are attractive architec¬ 
tural design alternatives in that they reduce 
the risk of not being able to accommodate 
the product-charge objectives. 

It provides a mechanism for incorporat¬ 
ing software quality objectives into soft¬ 
ware product development. This 
mechanism derives from the emphasis on 
identifying all types of objectives and con¬ 
straints during each round of the spiral. 
For example, Table 3 shows user- 
friendliness, portability, and reliability as 
specific objectives and constraints to be 
addressed by the SPS. In Table 1, security 
constraints were identified as a key risk 
item for the SPS. 

It focuses on eliminating errors and 
unattractive alternatives early. The risk- 
analysis, validation, and commitment 
steps cover these considerations. 

For each of the sources of project 
activity and resource expenditure, it 
answers the key question, “How much is 
enough?” Stated another way, “How 
much of requirements analysis, planning, 
configuration management, quality assur¬ 
ance, testing, formal verification, etc. 
should a project do?” Using the risk- 
driven approach, one can see that the 
answer is not the same for all projects and 
that the appropriate level of effort is deter¬ 
mined by the level of risk incurred by not 
doing enough. 

It does notin volve separate approaches 
for software development and software 
enhancement (or maintenance). This 
aspect helps avoid the “second-class citi¬ 
zen” status frequently associated with 
software maintenance. It also helps avoid 
many of the problems that currently ensue 
when high-risk enhancement efforts are 
approached in the same way as routine 
maintenance efforts. 

It provides a viable framework for inte¬ 
grated hardware-software system develop¬ 
ment. The focus on risk-management and 
on eliminating unattractive alternatives 
early and inexpensively is equally applica¬ 
ble to hardware and software. 

Difficulties. The full spiral model can be 
successfully applied in many situations, 
but some difficulties must be addressed 
before it can be called a mature, univer¬ 
sally applicable model. The three primary 
challenges involve matching to contract 
software, relying on risk-assessment 
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expertise, and the need for further elabo¬ 
ration of spiral model steps. 

Matching to contract software. The spi¬ 
ral model currently works well on internal 


software developments like the TRW- 
SPS, but it needs further work to match it 
to the world of contract software acqui¬ 
sition. 

Internal software developments have a 


great deal of flexibility and freedom to 
accommodate stage-by-stage commit¬ 
ments, to defer commitments to specific 
options, to establish minispirals to resolve 
critical-path items, to adjust levels of 
effort, or to accommodate such practices 
as prototyping, evolutionary develop¬ 
ment, or design-to-cost. The world of con¬ 
tract software acquisition has a harder 
time achieving these degrees of flexibility 
and freedom without losing accountabil¬ 
ity and control, and a harder time defin¬ 
ing contracts whose deliverables are not 
well specified in advance. 

Recently, a good deal of progress has 
been made in establishing more flexible 
contract mechanisms, such as the use of 
competitive front-end contracts for con¬ 
cept definition or prototype fly-offs, the 
use of level-of-effort and award-fee con¬ 
tracts for evolutionary development, and 
the use of design-to-cost contracts. 
Although these have been generally suc¬ 
cessful, the procedures for using them still 
need to be worked out to the point that 
acquisition managers feel fully comforta¬ 
ble using them. 

Relying on risk-assessment expertise. 
The spiral model places a great deal of reli¬ 
ance on the ability of software developers 
to identify and manage sources of project 
risk. 

A good example of this is the spiral 
model’s risk-driven specification, which 
carries high-risk elements down to a great 
deal of detail and leaves low-risk elements 
to be elaborated in later stages; by this 
time, there is less risk of breakage. 

However, a team of inexperienced or 
low-balling developers may also produce 
a specification with a different pattern of 
variation in levels of detail: a great elabo¬ 
ration of detail for the well-understood, 
low-risk elements, and little elaboration of 
the poorly understood, high-risk elements. 
Unless there is an insightful review of such 
a specification by experienced develop¬ 
ment or acquisition personnel, this type of 
project will give an illusion of progress 
during a period in which it is actually head¬ 
ing for disaster. 

Another concern is that a risk-driven 
specification will also be people- 
dependent. For example, a design 
produced by an expert may be imple¬ 
mented by non-experts. In this case, the 
expert, who does not need a great deal of 
detailed documentation, must produce 
enough additional documentation to keep 
the non-experts from going astray. 
Reviewers of the specification must also be 


Table 4. A prioritized top-ten list of software risk items. 


Risk item 

Risk management techniques 

1. Personnel 
shortfalls 

Staffing with top talent, job matching; teambuilding; 
morale building; cross-training; pre-scheduling key 
people 

2. Unrealistic 
schedules and 
budgets 

Detailed, multisource cost and schedule estimation; 
design to cost; incremental development; software 
reuse; requirements scrubbing 

3. Developing the 
wrong software 
functions 

Organization analysis; mission analysis; ops-concept 
formulation; user surveys; prototyping; early users’ 
manuals 

4. Developing the 
wrong user 
interface 

Task analysis; prototyping; scenarios; user 
characterization (functionality, style, workload) 

5. Gold plating 

Requirements scrubbing; prototyping; cost-benefit 
analysis; design to cost 

6. Continuing stream 
of requirement 
changes 

High change threshold; information hiding; incremental 
development (defer changes to later increments) 

7. Shortfalls in 
externally fur¬ 
nished components 

Benchmarking; inspections; reference checking; 
compatibility analysis 

8. Shortfalls in 
externally 
performed tasks 

Reference checking; pre-award audits; award-fee 
contracts; competitive design or prototyping; 
teambuilding 

9. Real-time 
performance 
shortfalls 

Simulation; benchmarking; modeling; prototyping; 
instrumentation; tuning 

10. Straining 

computer-science 

capabilities 

Technical analysis; cost-benefit analysis; prototyping; 
reference checking 


Table 5. Software Risk Management Plan. 


1. Identify the project’s top 10 risk items. 

2. Present a plan for resolving each risk item. 

3. Update list of top risk items, plan, and results 
monthly. 

4. Highlight risk-item status in monthly project reviews. 
• Compare with previous month’s rankings, status. 

5. Initiate appropriate corrective actions. 
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sensitive to these concerns. 

With a conventional, document-driven 
approach, the requirement to carry all 
aspects of the specification to a uniform 
level of detail eliminates some potential 
problems and permits adequate review of 
some aspects by inexperienced reviewers. 
But it also creates a large drain on the time 
of the scarce experts, who must dig for the 
critical issues within a large mass of non- 
critical detail. Furthermore, if the high- 
risk elements have been glossed over by 
impressive-sounding references to poorly 
understood capabilities (such as a new syn¬ 
chronization concept or a commercial 
DBMS), there is an even greater risk that 
the conventional approach will give the 
illusion of progress in situations that are 
actually heading for disaster. 

Need for further elaboration of spiral 
model steps. In general, the spiral model 
process steps need further elaboration to 
ensure that all software development par¬ 
ticipants are operating in a consistent 
context. 

Some examples of this are the need for 
more detailed definitions of the nature of 
spiral model specifications and milestones, 
the nature and objectives of spiral model 
reviews, techniques for estimating and 
synchronizing schedules, and the nature of 
spiral model status indicators and cost- 
versus-progress tracking procedures. An¬ 
other need is for guidelines and checklists 
to identify the most likely sources of proj¬ 
ect risk and the most effective risk- 
resolution techniques for each source of 
risk. 

Highly experienced people can success¬ 
fully use the spiral approach without these 
elaborations. However, for large-scale use 
in situations where people bring widely 
differing experience bases to the project, 
added levels of elaboration—such as have 
been accumulated over the years for 
document-driven approaches—are impor¬ 
tant in ensuring consistent interpretation 
and use of the spiral approach across the 
project. 

Efforts to apply and refine the spiral 
model have focused on creating a dis¬ 
cipline of software risk management, 
including techniques for risk identifica¬ 
tion, risk analysis, risk prioritization, risk- 
management planning, and risk-element 
tracking. The prioritized top-ten list of 
software risk items given in Table 4 is one 
result of this activity. Another example is 
the risk management plan discussed in the 
next section. 


Implications: The Risk Management 
Plan. Even if an organization is not ready 
to adopt the entire spiral approach, one 
characteristic technique that can easily be 
adapted to any life-cycle model provides 
many of the benefits of the spiral 
approach. This is the Risk Management 
Plan summarized in Table 5. This plan 
basically ensures that each project makes 
an early identification of its top risk items 
(the number 10 is not an absolute require¬ 
ment), develops a strategy for resolving the 
risk items, identifies and sets down an 
agenda to resolve new risk items as they 
surface, and highlights progress versus 
plans in monthly reviews. 

The Risk Management Plan has been 
used successfully at TRW and other 
organizations. Its use has ensured appro¬ 
priate focus on early prototyping, simula¬ 
tion, benchmarking, key-person staffing 
measures, and other early risk-resolution 
techniques that have helped avoid many 
potential project “show-stoppers.” The 
recent US Department of Defense stan¬ 
dard on software management, DoD- 
Std-2167, requires that developers produce 
and use risk management plans, as does its 
counterpart US Air Force regulation, AFR 
800-14. 

Overall, the Risk Management Plan and 
the maturing set of techniques for software 
risk management provide a foundation for 
tailoring spiral model concepts into the 
more established software acquisition and 
development procedures. 

W e can draw four conclusions 
from the data presented: 

(1) The risk-driven nature 
of the spiral model is more adaptable to the 
full range of software project situations 
than are the primarily document-driven 
approaches such as the waterfall model or 
the primarily code-driven approaches such 
as evolutionary development. It is partic¬ 
ularly applicable to very large, complex, 
ambitious software systems. 

(2) The spiral model has been quite suc¬ 
cessful in its largest application to date: the 
development and enhancement of the 
TRW-SPS. Overall, it achieved a high level 
of software support environment capabil¬ 
ity in a very short time and provided the 
flexibility necessary to accommodate a 
high dynamic range of technical alterna¬ 
tives and user objectives. 

(3) The spiral model is not yet as fully 
elaborated as the more established models. 
Therefore, the spiral model can be applied 
by experienced personnel, but it needs fur¬ 
ther elaboration in such areas as contract- 
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ing, specifications, milestones, reviews, 
scheduling, status monitoring, and risk- 
area identification to be fully usable in all 
situations. 

(4) Partial implementations of the spi¬ 
ral model, such as the Risk Management 
Plan, are compatible with most current 
process models and are very helpful in 
overcoming major sources of project 
risk.D 
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Confessions of a used-program salesman—programming-in-the-new 


OK, it’s time to fall on my sword 
again. Another revelation has just hit 
me right where it hurts the most—in the 
wallet. Having gone through the “old 
school” of programming (assembly lan¬ 
guage, Fortran, Cobol, and PL/I), I 
consider myself an experienced, battle- 
scarred veteran of many programming 
wars. But, as the result of an opportu¬ 
nity I couldn’t refuse, I have spent the 
last three years retooling at the “new 
school” of software engineering (Ada, 
Prolog, and Smalltalk). Now I consider 
myself a somewhat naive, battle-scared 
beginner thrust into the front line of 
new softwars. 

Regarding my business of developing 
and selling reusable programs, I have 
come to the realization that it is time to 
switch horses; that my programming-in- 
the-old mindset has reached its limits of 
productivity and profitability, and it is 
time to harness the new (to me) technol¬ 
ogy and adopt new programming 
paradigms to the business at hand. 

Reuse and programming-in-the-old 

As I reminisce about the good old 
days, I begin to realize that they were 
the “old days” and that there wasn’t 
really that much “good” about them 
(other than the fact that my ego was 
bigger and there was more hair on the 
top of my head). When people talk 
about growing pains, the birth of the 
programming profession gave a new 
meaning to the word labor. Key 
punches, and waiting three to four 
hours for a batch job to turn around 
(only to find you missed a comma in 
your JCL) hardly bring back sweet 
memories. We did the best we could 
with the coding forms and “flaw 
charts” * we had for tools. The field 
was young, and we were having too 
much fun to know any better. Besides, 
we were becoming legends in our own 
minds—who could argue with success? 

Fortran subroutine and assembler 
language macro libraries were the pri¬ 
mary technologies we had to ply our 
trade of reusable software. (APL and 
Lisp function libraries had some cute 


*1 first encountered this term in David Gries’ The 
Science of Programming. 


features that never really seemed to 
catch on with most mainframe macho 
machine-code mainliners.) Functional 
decomposition worked well—most of 
the time. The only problem with top- 
down stepwise refinement was that in 
the used-programming business we 
needed to work bottom-up to capitalize 
on our library of subroutines and 
macros. Working top-down and 
bottom-up, we sometimes didn’t meet 
in the middle—a somewhat annoying 
situation. Also, adding more 
parameters and writing larger macros 
(later called application generators) 
only scaled so far until they collapsed 
under their own complexity. I felt that 
the used-program business was not 
evolving, and lacked an adequate tech¬ 
nical foundation to build upon. 

Programming-in-the-new 

Has there been a revolution in the 
used-programming business, or has 
software technology just taken the path 
of least resistance, with the law of the 
bungle determining the survival of the 
witless? In my case, I certainly was 
skeptical that artificial intelligence 
would ever provide anything to make 
my job easier. All the hype that I read 
about expert systems sent me quickly 
searching for the “del” key. But, upon 
further examination, I found several 
really clever ideas lurking in the myths. 

Formal methods helped me assert the 
correctness of my reusable components 
as well as verify their interfaces. Lan¬ 
guage features such as user-defined 
types were abstract at first, but along 
with certain parameterization capabili¬ 
ties, they were just the type of thing I 
was looking for. Data abstraction and 
encapsulation along with information 
hiding became the basis for developing 
a collection of reusable components. 
Finally, programming by difference 
using hierarchies of types helped local¬ 
ize the common operations and distin¬ 
guish the unique characteristic of my 
reusable software. 

After wrestling with several new soft¬ 
ware development mythodologies, I 
realized that an object-oriented 
approach suited my top-down and 
bottom-up design style. Using a layered 


approach, I seldom ran into the prob¬ 
lem of designs not meeting in the mid¬ 
dle. I have always believed that what 
sets reusable software apart is how it is 
put together. These new technologies 
helped me take systems apart and put 
them back together more easily and 
with less expense in time and money. 

The expert system engineers had 
provided insight into one tough reuse 
problem that remained—How does one 
reuse software artifacts other than just 
code? In their search for storing knowl¬ 
edge, the AI researchers had tried vari¬ 
ous representation methods, which 
along with the sophisticated graphical 
programming environment provided the 
missing link in my reuse environment. 
Now I could capture the design deci¬ 
sions along with the design for future 
reuse using a Hypertext system. Fur¬ 
thermore, I could track what part of my 
requirements was satisfied by what part 
of my design and implemented in what 
part of my code. If my requirements 
changed, I could quickly find where the 
code needed to be changed. There was 
even some talk about parameterizing 
the requirements so the changes would 
automatically filter down to the imple¬ 
mentation. 

I still wasn’t done recycling and 
adapting expert system technology to 
program reuse; all the domain analysis 
techniques easily transferred to identify¬ 
ing and parameterizing new systems. 

Time and technology wait for no one, 
and technical obsolescence can rapidly 
reduce one’s ability to compete in the 
marketplace. I have switched so I can 
fight for my market share. Most of the 
software technologies that I have identi¬ 
fied in the previous section have been 
around at least 10-15 years (object- 
oriented programming was introduced 
in 1960). It has just taken this long for 
the price per MIPS to decrease enough 
to make the technology attractive for 
widespread reuse. The bottom line is 
that it makes cents—dollars and 
cents—to leverage the new technology. 

Will Tracz (your friendly used- 

program salesman) 

Computer Systems Laboratory 

Stanford University 
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The University of the Air 

The rapid pace of computer science 
innovation requires a rapid method of 
disseminating new ideas. Currently, 
ideas are distributed through class¬ 
rooms, conferences, laboratories, work¬ 
shops, seminars, and printed books and 
journals. Electronic communication 
technology and consumer electronic 
products make it possible to construct a 
national computer science university: a 
University of the Air. Broadcasting into 
potentially every programmer’s home, 
the video classes would quickly distrib¬ 
ute new ideas and new software tools, 
cutting the transition time between 
state-of-the-art and state-of-the- 
practice. 

The university is based on available 
technologies. The video signal would be 
broadcast nationally via satellite to 
home satellite dishes or local cable net¬ 
works. The material would include lec¬ 
tures, textual and graphic material, 
computer-aided instruction (CAI) pro¬ 
grams, public-domain software, knowl¬ 
edge bases, and broadcast electronic 
mail. 

A packet-switched network into a 
computer bulletin board system would 
provide electronic mail and conferenc¬ 
ing for tutoring, conducting study 
groups, submitting homework and 
exams, conducting group research, and 
providing feedback. High-performance 
home computer systems would provide 
the foundation for programming 
assignments, simulations, CAI, text 
editing, and communications control. 

The same technologies would support 
distributed research as well as teaching. 

Implementation of the university 
would occur in phases. 


Phase one: 

• Initiate the university. 

• Assemble video capture and editing 
hardware: build or rent studios. 

• Use “graveyard time” (12 to 6 
a.m.) on existing satellite tran¬ 
sponder and cable channels; home 
videocassette recorders could cap¬ 
ture the material at any time on any 
day. 

• Broadcast conferences, conference 
tutorials, guest lectures, demonstra¬ 
tions, and short courses. 

• Develop normal technical courses; 
focus on advanced material taught 
in only a few places. 

• Enhance the video production qual¬ 
ity with computer graphics, anima¬ 
tion, on-site footage, and excellent 
presentation. 


• Experiment with presentation 
methodologies. 

• Offer free auditing of this phase. 


Phase two: 

• Construct the feedback path. 

• Contract for low-cost long-distance 
communication, probably a packet- 
switched network. 

• Assemble the bulletin board 
system. 

• Decide on initial student fees and 
payment methods. 

• Arrange for exams to be physically 
mailed in, protected by legal (writ¬ 
ten) signature. 

• Create additional courses directed 
toward attaining a complete cur¬ 
riculum. 

• Offer extension course credits. 


• Make video modem available to 
students for recovery of text and 
software from video signal. 

• Define a standard computer sys¬ 
tem, based on a 32-bit architecture. 

• Broadcast public-domain software 
or encrypted, payment-required 
software, including class tools, 
assignments, CAI material, interac¬ 
tive animation tools, knowledge 
bases, and simulation tools. 

• Distribute textual and graphic 
material in a page description lan¬ 
guage for laser printing. 

• Broadcast group-addressed elec¬ 
tronic mail, general announce¬ 
ments, and schedules. 


Phase four: 

• Acquire full-time satellite tran¬ 
sponder; extend broadcast time to 
24 hours per day. 

• Use public key encryption to pro¬ 
tect homework and exams. 

• Offer credits and degrees. 

• Acquire accreditation. 


In parallel: 

• Start research projects. 

• Have individuals cooperate on stan¬ 
dard computer science problems 
through the network. 

• Research new problems based on 
the university implementation tech¬ 
nologies. 

• Research teaching methodologies, 
teaching tools, computer-aided 
instruction, and presentation tech¬ 
nologies. 


In parallel: 

• Develop an expert system shell for 
tutoring courses. 

• Broadcast specific knowledge base 
as part of the course. 

In parallel: 

• Develop a computer science refer¬ 
ence library on optical disk. 

• Broadcast technical articles and 
reports. 


In parallel: 

• Develop specific courses and exam 
material to support future individ¬ 
ual professional licensing. 


In parallel: 

• Develop very-large-scale- 
integration chips, add-on cards, 
and driving software for the stan¬ 
dard computer system for hardware 
courses. 

• Expand into hardware-related 
courses by converting the computer 
into an oscilloscope, waveform 
generator, logic analyzer, logic sig¬ 
nal generator, logic simulator, and 
in-circuit emulator. 

The technology is available now to 
construct the University of the Air. One 
problem is how to fund the university. 
The phased design starts out as a free 
service; it would require philanthropic 
money, economic-paranoia money, or 
long-term investment money. Selling air 
time for product-oriented classes is pos¬ 
sible. In the last phase, the university 
could charge the same tuition (plus 
books and lab fees) as a private com¬ 
puter science university. Profits could 
be realized from the sale of video tapes, 
computer software and hardware, text¬ 
books, study aids, and specialized 
knowledge. The cost of the required 
hardware also will continue to rapidly 
decrease. 

Two other key questions regarding 
the feasibility of the university are (1) 
How much should a computer science 
professional pay annually to maintain 
and increase his/her skills? and (2) How 
much should a company pay annually 
to maintain and increase the skills of its 
computer science employees? 

The University of the Air is techni¬ 
cally feasible now. Is the need strong 
enough to induce its creation? 

Randall Neff 

Computer Systems Laboratory 

Stanford University 
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STANDARDS 


Editor: Helen M. Wood, National Bureau of Standards, B154 Technology, Gaithersburg, MD 20899; (301) 975-3240 


IEEE Standards Board approves new 
Computer Society interconnection project 


Review, comment 
sought on Cobol, SQL 

Accredited Standards Committee X3 
on Information Processing Systems is 
seeking public comment on two draft 
proposed American National 
Standards. 

The second two-month public review 
period on X3.23A-198x, Programming 
Language Cobol, Addendum 1 Intrinsic 
Function Module (IFM), will conclude 
May 24. Standard X3.23A-198x adds an 
IFM to the current programming lan¬ 
guage for Cobol. 

Technical Committee X3J4 Cobol 
further modified this proposed adden¬ 
dum in response to comments received 
during the initial public review. The 
IFM provides the capability to reference 
a data item whose value is derived auto¬ 
matically at the time of reference during 
the execution of the object program. 

The four-month review and comment 
period on X3.168-198x, Embedding of 
SQL Statements into Programming 
Languages, will continue through July 
10. SQL is a database interface 
language. 

The standard specifies embedded syn¬ 
tax for including SQL data manipula¬ 
tion language statements in an 
application program. Such embedded 
syntax is defined as a shorthand nota¬ 
tion for a standard application pro¬ 
gram, written in a standard 
programming language in which the 
embedded SQL statements have been 
replaced with explicit “calls” to data¬ 
base procedures. 

This standard is dependent on the 
standard for Database Language SQL 
(ANSI X3.135-1986, ISO 9075) that 
specifies the semantics of SQL data 
manipulation language statements. 

Copies of the draft standards may be 
purchased from Global Engineering 
Documents by dialing (800) 854-7179 
(within the US) or (714) 540-9870 (out¬ 
side the US). 


The IEEE Standards Board approved 
a new Computer Society standards 
development project, A Standard for 
Interconnections Among Computing 
System Engineering Tools, when the 
panel met March 9. 

The project, PI 175, is sponsored by 
the society’s Standards Coordinating 
Committee in cooperation with the CS 
Professional Tools Task Force. 

In other action, the board approved a 
society request to terminate the follow¬ 
ing three projects: P1079, Circuit and 
Physical Design Description Language; 
PI 134, A Standard for Personal Com¬ 
puter Basic Input/Output Software; 
and PI 166, Very High Density Logic 
Model Guidelines. 


A special joint meeting of groups 
proposing standards for computer- 
aided software engineering tools will be 
conducted July 12 in Cambridge, Mass. 
The meeting will be held in conjunction 
with CASE 88, the second International 
Workshop on Computer-Aided Soft¬ 
ware Engineering cosponsored by the 
Computer Society. 

A number of organizations are 
proposing standards for CASE tools in 
areas including tool design, dictionary 
content, tool interfaces, and inter¬ 
change of data between tools. 

The meeting is expected to attract 
representatives from the IEEE profes¬ 
sional tools task force, the Electronic 
Industries Association, the American 
National Standards Institute, the 
National Bureau of Standards, and 


The board also approved 1003.1, 
Portable Operating System for Com¬ 
puter Environments (Posix), as a full 
standard. Development of this standard 
was sponsored by the society’s Techni¬ 
cal Committee on Operating Systems. 

Work is continuing on additional 
Posix projects, including conformance 
tests, open systems architecture, and 
security. 

For complete details on current CS 
standards projects or information on 
purchasing draft or final standards, 
contact Richard Cain, Standards Coor¬ 
dinator, Computer Society, 1730 Mas¬ 
sachusetts Ave. NW, Washington, DC 
20036-1903; (202) 371-0101. 


prominent CASE vendors. 

“There are now so many independent 
standards efforts affecting CASE that 
we are in danger of losing the benefits 
that unifying standards could provide 
for the advancement of the field,” said 
Elliot Chikofsky, CASE 88 general 
chair. “Many of us recognize that an 
explosion of incompatible standards 
will result in no standard at all. 

“The coordinating meeting will ena¬ 
ble us to understand and rationalize 
existing standards efforts and examine 
the scope needed for CASE standards.” 

Additional information on the work¬ 
shop or the standards coordinating 
meeting may be obtained from Pamela 
Meyer, c/o Index Technology Corp., 
One Main St., Cambridge, MA 02142; 
(617) 494-8200, ext. 1988. 


CASE standards coordinating meeting 
scheduled in July 
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C °ZS, NEWS 


Editor: Sallie Sheppard, Office of Associate Provost for Honors Program and Undergraduate Studies, 
Texas A&M University, College Station, TX 77843; (409) 845-3210 


Three researchers capture first Gordon Bell 
Award for computing speedup 


Software Life-Cycle 
Processes Standard 
issued for review, 
comment 

After producing several preliminary 
versions, the working group assigned to 
write the IEEE Standard for Software 
Life-Cycle Processes has designated a 
first draft on Project P1074. The work¬ 
ing group is now calling for public 
review and comment. 

Project P1074 was initiated in August 
1984 to define the processes mandatory 
for developing and maintaining critical 
software. The adopted standard will 
emphasize the software processes them¬ 
selves rather than the time-sequencing 
of the processes. 

The document will not mandate a 
standard IEEE software life-cycle 
model but will require that, as a normal 
part of software development, the soft¬ 
ware developer must select and follow a 
life-cycle model. The processes 
described in the standard, and the 
activities that comprise the processes, 
must then be mapped into the selected 
life-cycle model. 

The working group responsible for 
preparing the standard has met 10 times 
and has produced five versions of a 
straw man for the document. Up until 
now, the working group has felt the 
straw men contained too many holes 
and unwritten assumptions to be con¬ 
sidered first drafts. Thus, distribution 
of the document has been restricted to 
the active working group members. 

However, the group recently con¬ 
cluded that the document is now stable 
enough to be designated a first draft. 
Therefore, all future versions will be 
distributed for public review and com¬ 
ment. Instructions for submitting com¬ 
ments are included in a cover letter 
accompanying each copy of the draft. 

To be considered at a particular meet¬ 
ing, comments must be received about 
two weeks before the meeting date. 

The working group will conduct its 
third and final 1988 meeting October 
11-13 in San Jose, Calif. The first two 
sessions of 1989 will be held in February 
and May at Salt Lake City, Utah, and 
Rochester, N.Y., respectively. 

Persons interested in joining the 
working group, attending meetings, 
and/or participating in developing the 
standard should contact working group 
chair David J. Schultz, Computer 
Sciences Corp., 8728 Colesville Rd., Sil¬ 
ver Spring, MD 20910-3918. His phone 
number is (407) 982-0592 until Septem¬ 
ber 1, 1988; afterwards, it will be (301) 
589-1545. 


Robert Benner, John Gustafson, and 
Gary Montry of the Parallel Processing 
Division of Sandia National Laborato¬ 
ries have won the first $1,000 Gordon 
Bell Award. 

Their entry captured top 1987 honors 
for processing speedup on a general- 
purpose multiple-instruction, multiple- 
data computer when Bell announced the 
competition results at Compcon Spring 
88 March 1 in San Francisco. 

Since no single entry qualified to win 
the second $1,000 earmarked for 
presentation to the best entry in the 
special-purpose category, that money 
was divided among three other notable 
entrants in the general-purpose cate¬ 
gory. Three judges did the evaluating. 

Bell, vice president of engineering at 
Ardent Computer, is sponsoring the 
awards for the next 10 years to recog¬ 
nize outstanding achievement in the 
application of supercomputers to scien¬ 
tific and engineering problems. 

IEEE Software, which carries com¬ 
plete details about the program and 
entries in its May issue, administers the 
judging and presentations, although 
neither the Computer Society nor the 
IEEE sponsors the awards. 

In making the top general-purpose 
presentation, Bell cited the work Ben¬ 
ner, Gustafson, and Montry did in 
achieving parallel-processing speedups 
ranging from 400 to more than 600 
times faster than on a single processor. 
The judges had anticipated a winning 
speedup of no more than 50. 

The researchers used a 1,024-proces- 
sor N-Cube supercomputer to run 
three production applications: a beam 
stress analysis, a surface-wave simu¬ 
lation, and an unstable fluid-flow 
model. 


The winning research team subsequent¬ 
ly donated the prize to the Association 
for Retarded Citizens in Albuquerque, 
where Sandia National Laboratories is 
located. 

The other $1,000 award was split up 
to encourage research leading to 
speedup on practical scientific and 
engineering applications. 

Second-place honors and $300 were 
presented to Erik Benedictus of AT&T 
Bell Laboratories, Marina Chen and 
Jingke Li of Yale University, and 
Geoffery Fox and David Walker of the 
California Institute of Technology for 
work on the Caltech and N-Cube hyper¬ 
cubes. They submitted results from 
three problems: a computational kernel 
with a speedup of 98; a quantum- 
chronodynamics calculation with a 
scaled speedup of 458; and a circuit 
simulation with a speedup of 39. 

Robert Chervin of the National Cen¬ 
ter for Atmospheric Research won 
honorable mention and $500 for a 
global ocean-climate model running at 
450 million floating-point operations 
per second on all four processors of a 
Cray X-MP/48. 

A special award of $200 went to 
Stavros Zenios of the Wharton School 
at the University of Pennsylvania for 
his use of a 16,384-processor Connec¬ 
tion Machine to solve nonlinear 
network-optimization problems. 

Entries are being accepted for the 
1988 awards and must be submitted by 
December 31, 1988, to Ted Lewis, 
Editor-in-Chief, IEEE Software, c/o 
Computer Science Dept., Oregon State 
University, Corvallis, OR 97331. 

The rules are listed in the May issue 
of IEEE Software and also may be 
obtained by circling Reader Service No. 
181. 
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Proposed bylaws amendments establish 
Computer Society Press Board 


Meeting March 4 in San Fran¬ 
cisco, the Computer Society Board 
of Governors passed for the first 
time amendments to the society’s 
bylaws establishing a Computer 
Society Press Board. 

This change was recommended to 
the board by the Constitution and 
Bylaws Committee, chaired by 
President-elect Kenneth R. Ander¬ 
son, in recognition of the increasing 
periodical and non-periodical publi¬ 
cation demands on the vice president 
for publications. 

In addition, a proposed new sec¬ 
tion to Article III would give the 
Board of Governors the authority to 
define a procedure for presenting 
opposing views on voting matters 


placed before the society’s mem¬ 
bership. 

For review by CS members, the 
proposed text of the sections 
involved is published here, along 
with the current wording in the 
bylaws. In the proposed version, 
new or rearranged material is printed 
in italics. 

Member comments are solicited. 
Please send them to Kenneth R. 
Anderson, Chair, Constitution and 
Bylaws Committee, Computer Soci¬ 
ety, 10662 Los Vaqueros Circle, Los 
Alamitos, CA 90720. 

The Board of Governors is 
expected to vote on the changes for 
the second time at its meeting June 
17 in Anaheim, Calif. 


Computer Society Press 
Board 

A new Article X is to be added (with 
the remaining items appropriately 
renumbered and amended as necessary). 

Article X, Press Activities 

Section 1, Computer Society Press Board 

Proposed wording: The Computer Society 
Press Board shall be responsible for recom¬ 
mending to the Board of Governors all poli¬ 
cies for Computer Society Press activities. It 
shall establish activities and supporting oper¬ 
ations, and monitor their execution to assure 
conformance with approved policies. It shall 
be chaired by the vice president of the Com¬ 
puter Society Press Board, and shall consist 
of the following members: the editor-in-chief 
of the Computer Society Press and the chairs 
of the Press Operations Committee, the 
Planning Committee, the New Products 
Committee, the Sales and Promotions Com¬ 
mittee, and other members appointed by the 
vice president of the Computer Society Press 
Board. The chairs of these committees shall 
be appointed by the president on the recom¬ 
mendation of the vice president of the Com¬ 
puter Society Press Board. 


Section 2, Standing Committees 

The functions of the Standing Committees 
mentioned in Section I shall be defined in the 
Computer Society Policies and Procedures 
Manual (PPM). Other standing committees 
may be defined in the PPM. 


Section 3, Editor-in-Chief 

(I ) There shall be an editor-in-chief 

appointed. This individual shall report 
to the vice president of the Computer 
Society Press Board. 

(2 ) The Computer Society Press Board 
shall recommend to the president one 
or more candidates for the editor-in- 
chief position. The president, with the 
advice and consent of the Board of 
Governors, shall appoint the editor-in- 
chief for a definite period not to 
exceed two years. 


Article XI, Publications Activities 
Section 1, Publications Board 

Current wording: The Publications Board 
shall formulate the policies of those Society 
publications edited by editors-in-chief and 
shall monitor the execution of those policies. 
The Publications Board shall be chaired by 
the vice president for publications and con¬ 
sist of the following members: the chairper¬ 
sons of the Transactions Advisory Committee, 
Magazine Advisory Committee, Press Advi¬ 
sory Committee, all editors-in-chief, the 
Society’s division representative on the IEEE 
Publications Board, the representative from 
the Technical Activities Board, and addi¬ 
tional members appointed by the vice presi¬ 
dent for publications. The chairpersons of 
the advisory committees shall be appointed 
by the president with the recommendation of 
the vice president for publications; the 


appointment of editors-in-chief is specified 
in Section 3 of this article. The president may 
delegate authority for such appointments to 
the vice president. 

Proposed wording: The Publications 
Board shall formulate the policies of those 
Society periodical publications edited by 
editors-in-chief and shall monitor the execu¬ 
tion of those policies. The Publications 
Board shall be chaired by the vice president 
for publications and consist of the following 
members: the chairpersons of the Transac¬ 
tions Advisory Committee, Magazine Advi¬ 
sory Committee, all periodical editors-in- 
chief, the Society’s division representative 
on the IEEE Publications Board, the repre¬ 
sentative from the Technical Activities 
Board, and additional members appointed 
by the vice president for publications. 

The chairpersons of the advisory commit¬ 
tees shall be appointed by the president 
with the recommendation of the vice presi¬ 
dent for publications; the appointment of 
editors-in-chief is specified in Section 3 
of this article. The president may delegate 
authority for such appointments to the vice 
president. 

Section 2, Advisory Committees 

Current wording: There shall be a Trans¬ 
actions Advisory Committee, a Magazine 
Advisory Committee, and Press Advisory 
Committee. Each advisory committee shall 
advise the editors-in-chief to meet the publi¬ 
cations standards set by the Publications 
Board, advise the Publications Board on 
policy matters, inform the Publications 
Board about the ongoing publications activi¬ 
ties and plans, assist the Publications Board 
in recommending candidates for editors-in- 
chief as specified in the bylaws, and under¬ 
take other assignments as specified by the 
Publications Board. The members of each 
advisory committee shall be appointed by the 
vice president for publications. 

Proposed wording: There shall be a Trans¬ 
actions Advisory Committee and a Magazine 
Advisory Committee. Each advisory com¬ 
mittee shall advise the editors-in-chief to 
meet the periodical publications standards 
set by the Publications Board, advise the 
Publications Board on policy matters, 
inform the Publications Board about the 
ongoing periodical publications activities and 
plans, assist the Publications Board in 
recommending candidates for periodical 
editors-in-chief as specified in the bylaws, 
and undertake other assignments as specified 
by the Publications Board. The members of 
each advisory committee shall be appointed 
by the vice president for publications. 

Section 3, Editors-in-Chief 

Current wording: (1 ) There shall be an 
editor-in-chief appointed for each periodical 
publication. There shall be editors-in-chief 
appointed for tutorials and other nonperiod¬ 
ical publications as required. These individuals 
shall report to the vice president for publi¬ 
cations. 

(2) The Publications Board shall recom¬ 
mend to the president one or more candi- 
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dates for each editor-in-chief position at 
various times as required. The president, 
with the advice and consent of the Board of 
Governors, shall appoint the editor-in-chief 
for a definite period not to exceed two years. 
In the case of a new periodical, the initial 
appointment may be for a maximum of three 

Proposed wording: (1) There shall be an 
editor-in-chief appointed for each periodical 
publication. These individuals shall report to 
the vice president for publications. 

(2) The Publications Board shall recom¬ 
mend to the president one or more candi¬ 
dates for each editor-in-chief position at 
various times as required. The president, 
with the advice and consent of the Board of 
Governors, shall appoint the editor-in-chief 
for a definite period not to exceed two years. 
In the case of a new periodical, the initial 
appointment may be for a maximum of three 
years. 

Article VII, Conferences and Tutorials 
Section 4, Tutorials Committee 

Current wording: There shall be a Tutorials 
Committee responsible for establishing 
guidelines for developing and evaluating 


tutorials on subjects within the scope of the 
Society, except that the review of the tutorial 
texts published by the Computer Society 
Press is the responsibility of the Publications 
Board and that the solicitation and delivery 
of tutorials at conferences, tutorial weeks, 
and chapters is the responsibility of the spon¬ 
soring entities. The Tutorials Committee 
shall consist of the following members: the 
chairperson of the Chapters Tutorials Com¬ 
mittee, the representative from each Tutorial 
Week Steering Committee, and additional 
members appointed by the Committee chair¬ 
person. 

Proposed wording: There shall be a 
Tutorials Committee responsible for estab¬ 
lishing guidelines for developing and evaluat¬ 
ing tutorials on subjects within the scope of 
the Society, except that the review of the 
tutorial texts published by the Computer 
Society Press is the responsibility of the 
Computer Society Press Board and that the 
solicitation and delivery of tutorials at con¬ 
ferences, tutorial weeks, and chapters is the 
responsibility of the sponsoring entities. The 
Tutorials Committee shall consist of the fol¬ 
lowing members: the chairperson of the 
Chapters Tutorials Committee, the represen¬ 
tative from each Tutorial Week Steering 


Committee, and additional members 
appointed by the Committee chairperson. 


Position Statements 

The bylaws currently do not provide 
a method for presenting an opposing 
view on voting matters brought to the 
franchised membership. A proposed 
new section to Article III provides the 
Board of Governors the power to 
define, in the Policies and Procedures 
Manual, such a procedure. 

Article III, Board of Governors 
Section 13, Position Statements 

Proposed wording: When voting matters 
are before the Board by means other than at 
a meeting or before the membership by mail 
ballot such as for a Constitutional Amend¬ 
ment, the opportunity for presenting an 
opposing view shall be provided. The Poli¬ 
cies and Procedures Manual (PPM) may pre¬ 
scribe the conditions and procedures for 
presenting an opposing view. 


Iwasaki receives CS Technical Achievement 
Award during standards conference 


Shun-Ichi Iwasaki, director of the 
Research Institute of Electrical Com¬ 
munications at Tohoku University in 
Sendai, Japan, received the Computer 
Society’s Technical Achievement Award 
during a Compstan 88 luncheon 
ceremony in the Washington, D.C., 
area March 21. 

Helen M. Wood, the society’s vice 
president for standards, presented the 
award to Iwasaki in recognition of his 


major contributions to high-density 
storage technology. The Technical 
Achievement Award is presented for 
outstanding and innovative contribu¬ 
tions to the fields of computer science 
or computer technology that have sig¬ 
nificantly promoted technical progress 
in these fields during the last 10 to 15 
years. 

Society service awards were also 
presented at Compstan in recognition 


of contributions to the CS standards 
program. 

Meritorious Service Awards went to 
Thomas Hannan and Laurel Kaleda, 
while Certificates of Appreciation were 
presented to Louise Germani, John 
Hines, Thomas Kurihara, and Peter 
Prinzivalli. 

They were among 31 persons chosen 
to receive awards for service in the CS 
standards program during 1987. 



Helen Wood (second from left), Computer Society vice president for standards, officiated at the March 21 Compstan 88 
awards ceremony. Pictured are (left to right) Tom Kurihara, Wood, Peter Prinzivalli, John Hines, Tom Hannan, Laurel 
Kaleda, Shun-Ichi Iwasaki, and Louise Germani. 
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NEWS FROM THE COMMITTEE ON PUBLIC POLICY 


Information-security research called 
‘adequate’ in IEEE TAB report 


Ralph J. Preiss, COPP Chair 

Information-security research is ade¬ 
quate, but IEEE should develop a state¬ 
ment on public-key techniques, the 
technology that will have the greatest 
impact. These conclusions, from an 
assessment drafted for the IEEE Tech¬ 
nical Activities Board, were reported by 
Jerry Jennings during the Monday, 
February 29, meeting of the Computer 
Society’s Committee on Public Policy. 

The IEEE TAB assessment of the 
state of R&D in information-security 
technology was drafted by Jennings, 
who chairs the COPP Subcommittee 
for Privacy/Security, and by J.K. 
Omura of the IEEE Information The¬ 
ory Group and G.R. Ritchie of the 
IEEE Communications Society. 

The TAB report reads in part, “As 
we move toward an open information¬ 
intensive society with widely used com¬ 
puter/communication networks, the 
opportunities for information crimes 
increase. This includes the destruction 
and corruption of information, coun¬ 
terfeiting, theft, disclosure to unautho¬ 
rized parties and unintentional access to 
legitimate information system users. To 
cope with these threats, users need tech¬ 
niques for access control, user identifi¬ 
cation, transaction authentification, 
prevention of interception and dis¬ 
closure, and preservation of informa¬ 
tion integrity. 

“Information security consists of 
roughly two important parts: technol¬ 
ogy and procedures. Most known 
breakdowns in information security can 
be traced to a weakness in procedure or 
the lack of discipline in existing proce¬ 
dures ... 

“The widespread availability of Data 
Encryption Standard (DES) chips, NBS 
endorsement of this>;algorithm, and the 
amount of public information about the 
algorithm have led to the widespread 
user acceptance of the DES as a means 
of securing information for both real¬ 
time and non-real-time applications. 

The primary problem associated with 
the use of DES is key management. 

“Public-key techniques ... is the one 
technology that the [report authors] 
believe will have the greatest impact on 
information security ... [since] ... it is 
not necessary for secret information to 
be handled by people, which has always 


been the weakest part of information 
security ... and off-line authentication 
and verification can be done without 
any secret information or personalized 
data available. [The latter] is especially 
important in large distributed systems 
such as off-line point-of-sale authenti¬ 
cation of financial smart cards.” 

The conclusions reached were that 

(1) research in the technology 
associated with information is ade¬ 
quate, as evidenced by several interna¬ 
tional meetings a year in this area, and 

(2) a synthesis of this research and a 
position statement on the effectiveness 
of the technology are needed. 

The TAB report goes on to recom¬ 
mend that the IEEE develop a state¬ 
ment on public-key techniques and, 
perhaps, propose that a standard be 
established. The statement should 
include 

(1) current and planned applications, 
as well as the status of existing patents 
in this area; 

(2) strengths of the various specific 
public-key techniques—for example, 
the Diffie-Hellman and Rivest-Shamir- 
Adleman (RSA) systems—as a function 
of the bit size of the modulus; and 

(3) enough information to permit 
users to become confident about the 
strength of specific forms of public-key 
implementations. 

A copy of the report may be obtained 
by writing to Jennings at Laddis Corp., 
PO Box 2008, Dearborn, MI 48123 or 
by circling number 180 on the Reader 
Service Card (p. 120A). 

Other business discussed at the 
COPP meeting included the appoint¬ 
ments of Paul Davis as COPP vice chair 
and J. Timothy Headley as the 1988 
secretary-treasurer; the need to deter¬ 
mine whether COPP should be pressing 
for a US national computer policy; 
East/West technology transfer issues; 
and progress in the plan to provide an 
experts directory for use in providing 
expert witnesses in computer-related 
public policy issues. 

The next COPP meeting will be held 
May 17 at Computer Society headquar¬ 
ters in Washington, DC, from 10 a.m. 
to 3 p.m. Reservations are required and 
may be made until May 13 by calling 
Ralph Preiss at (914) 435-8185. 


Prototype e-mail system 
goes on line 

The National Science Foundation and 
more than a dozen universities plan to 
begin using UMExpres, a prototype of 
an electronic editing and mailing system 
for exchanging complex scientific docu¬ 
ments between different brands of com¬ 
puters. 

The system was designed to make it 
easier to create, edit, and transmit 
documents containing text and numeri¬ 
cal and symbolic data as well as images, 
drawings, charts, graphs, and photo¬ 
graphs. When UMExpres transmits a 
document, it also transmits the docu¬ 
ment’s underlying structure, so the 
recipient has the tools to edit the docu¬ 
ment and return it to the sender. 

The system is an early product of the 
Experimental Research in Electronic 
Submission (Expres) project, a three- 
year, $6 million NSF project begun in 
October 1986 with funding evenly 
divided between the University of 
Michigan and Carnegie Mellon Univer¬ 
sity. Apple Computer, Apollo Com¬ 
puter, Digital Equipment, IBM, and 
Sun Microsystems are providing hard¬ 
ware for the development and deploy¬ 
ment of UMExpres, as well as advice 
and technical support. 

A limited number of researchers at 
the University of Michigan and more 
than a dozen other universities, as well 
as NSF program managers in Washing¬ 
ton, D.C., will use UMExpres to evalu¬ 
ate and refine the prototype. The 
system’s first test will be as a vehicle for 
submitting grant proposals to NSF. The 
prototype will be available to program 
managers in computer and information 
sciences, engineering, atmospheric 
sciences, astronomy, economics, and 
biological sciences. 

In a release announcing the system’s 
test, A1 Thaler, NSF program manager 
for the Expres project, said one of the 
project’s objectives is to reduce the 
“bizarre and obscene quantities of 
paper” generated by the 40,000 
research proposals received by NSF 
annually. A broader goal is to enable 
scientists to communicate quickly and 
frequently among themselves and to 
share research results and tools. 
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Study shows schools must control R&D cost burden 


Failure to rein in costs associated 
with research and development facilities 
could result in the loss of scholars to 
institutions that are better able to con¬ 
trol indirect costs, a Stanford Univer¬ 
sity task force concluded after a 
two-year study. 

The study showed that federal fund¬ 
ing of college-based R&D facilities 
dropped from more than $350 million 
in 1965 to approximately $50 million in 
1984. Colleges and universities have 
sought reimbursement for their 
increased R&D expenses through 
indirect charges for depreciation, opera¬ 
tion, and maintenance of facilities. 

Such charges accounted for more than 


75 percent of the increase in Stanford’s 
indirect costs over the last decade. 

When expressed as a percentage of 
direct costs, such as salaries, Stanford’s 
indirect cost rate rose from 58 percent 
in 1978 to 68 percent in 1986. The cur¬ 
rent rate is 73 percent. Meanwhile, the 
average government grant has remained 
relatively constant in real dollars. Thus, 
fewer dollars are available to scholars 
for the direct costs of research. 

Other colleges and universities 
experienced a similar increase, the study 
found. The average indirect cost rate 
was 62.6 percent. 

The faculty task force noted that 
some institutions, such as MIT, Johns 


Hopkins, and the University of Penn¬ 
sylvania, have reduced their indirect 
cost rates in spite of increased overhead 
costs comparable with those of other 
research universities. 

“If this signals a break in the trends 
of the past 20 years,” the task force 
report stated, “the temporary declines 
in competitiveness that Stanford 
appears to have suffered after past 
increases in the indirect cost rate could 
become permanent after future 
increases. . . . 

“Eventually, this would lead to the 
defection of . . . scholars to universities 
with a more competitive indirect cost 
rate.” 


NSF awards graduate fellowships 


The National Science Foundation has 
offered fellowships for graduate study 
to 685 college and university students, 
including 40 fellowships in computer 
science and 145 in engineering, most of 
which are in the areas of electrical and 
electronic engineering. 


Nearly 5,150 students submitted 
applications in the nationwide competi¬ 
tion. Panels of scientists, assembled by 
the National Research Council of the 
National Academy of Sciences, evalu¬ 
ated applications, with final selections 
made by the NSF. 


The fellowships provide a stipend of 
$12,300 per year for full-time graduate 
study. An annual cost-of-education 
allowance of $6,000 is also provided by 
NSF, in lieu of all tuition and fees, to 
the US institution selected by each 
fellow. 


Computer devoted to modeling atomic behavior 


Researchers at AT&T Bell Laborato¬ 
ries have built a special-purpose com¬ 
puter to study the interatomic forces in 
materials used in electronic devices, 
such as the chemical bonds between 
atoms in silicon. 

The current version of the AT&T 
Optimized Materials Simulator (Atoms) 
calculates atom movements about 30 
percent faster than a commercial super¬ 
computer. The next version will use par¬ 
allel processing to solve the molecular 
dynamics problem and is expected to 
operate about four times faster than a 
supercomputer. 

Atoms can help determine how to 
reduce defects during crystal growth 
and processing of silicon, according to 
the company. George Gilmer, a 
materials scientist at AT&T Bell, and 
Marcia Grabow have used the machine 
to study the motion of atoms that 
occurs during melting and recrystalliza- 
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tion of silicon, and the formation of a 
thin film on the surface of a silicon 
wafer. 

Atoms can also be programmed to 
model other kinds of physical systems 


The Alabama Supercomputer Net¬ 
work successfully completed a 30-day 
acceptance test period in which it 
provided users with 99.9 percent system 
availability. The state required a 95 per¬ 
cent “up time” during the test. 

Elements of the system monitored 
during the test included the Cray X- 
MP/24 supercomputer, the network 
system, all nodal processors, and the 
front-end processors at the central site. 
Testing was conducted at Cummings 
Research Park West in Huntsville, Ala., 


using an approach called finite element 
analysis, which is used to study stress in 
bridges, drag coefficients of automo¬ 
biles, and solidification of metal 
castings. 


Network OK’d 

where the supercomputer is located. 

The initial network consists of eight 
node sites located at the University of 
Alabama at Huntsville, the University 
of Alabama at Birmingham, the Uni¬ 
versity of Alabama, the University of 
South Alabama in Mobile, the state’s 
Data Systems Management Division in 
Montgomery, the National Fertilizer 
Development Center/University of 
North Alabama in Muscle Shoals, 
Auburn University, and Troy State Uni¬ 
versity. 


Alabama Supercomputer 
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Microsoft’s high-performance languages 

Richard H. Eckhouse, Jr., New Product Reviews editor 


In the fall of 1987, Microsoft person¬ 
nel toured the country offering a 
“Focus on Technology” seminar for 
editors and reviewers. With a large 
number of new products to be released 
shortly, Microsoft wisely felt that a 
day’s worth of technical sessions would 
help put all of their efforts into better 
perspective. The day was divided into 
five sessions covering interpreter tech¬ 
nology, development environments, 
shared compiler technology, OS/2 
development tools, and benchmark 
strategies. 

Each of the session presenters was a 
project leader for one of the next- 
generation products scheduled for 
release. The firsthand experience of 
each session leader, the well-thought- 
out organization of the presentations, 
and the free-ranging exchange between 
developers and critical reviewers made 
this an outstanding opportunity. Those 
in my group felt that we could appreci¬ 
ate what had been done to improve a 
particular product and understand why 
the developers had taken a particular 
approach. We also came away with a 
glimpse of what the future would bring. 

Now, after many months of experi¬ 
ence with several of these new products, 
namely QuickBasic 4.0, C 5.0 and 
QuickC, Fortran (reviewed by Daniel 
McAuliffe), and Masm 5.0,1 can offer 
some insights into what these latest ver¬ 
sions have to offer. However, before 
jumping into that, let me at least 
describe some of the other areas 
presented at the seminar. 


Benchmarking 

strategies 

The question with regard to bench¬ 
marking was, how do you design a 
benchmark to test both the speed and 
the usefulness of a new product? Typi¬ 
cally a user wants to know something 
about code quality (such as the size and 
speed of the generated code), compiler 
speed, and the limits for the various 
modules and include files that make up 
a complete program. Secondary issues 


relate to features and extensions, con¬ 
formance to standards, and documen¬ 
tation. 

Often a benchmark will offer little 
more than an abstract result, such as 
“three times faster” or “half as big.” 
Sometimes it is subjective: “I liked it 
better.” Most often a benchmark is 
written to test a reviewer’s 
hypothesis—“Is it faster?”—based on a 
limited evaluation using a short code 
segment. In the end, the results gener¬ 
ated are useless to the user. 

Microsoft’s stated objective during 
this session was to outline the issues, 
discuss the current set of benchmarks 
(from the good to the bad to the ugly), 
explain how to interpret the results 
generated, improve upon the existing 
set of benchmarks, and plan for the 
future. They expressed specific interests 
in dealing with an optimizing compiler 
(and what it does to a poorly con¬ 
structed benchmark), testing while run¬ 
ning on a protected-mode operating 
system using large or even huge memory 
models, and understanding what the 
user is really trying to benchmark. 

OS/2 development tools 

Clearly the underlying strategy of a 
PC operating system changes with the 
introduction of OS/2. After all, it pro¬ 
vides a new process structure and a new 
applications interface architecture along 
with a new presentation manager. 

What, then, are the tools and how do 
you use them under OS/2? This 
Microsoft session focused on the 
changes the user will see. However, 
because a separate review of OS/2 is 
scheduled to appear in the July 1988 
issue of IEEE Software, I won’t go into 
the subject here. 

Development 

environments 

Microsoft’s announced strategy is to 
provide integrated environments that 
serve the user’s needs in creating an 


application. This translates into syntax- 
directed editors that link with debuggers 
to facilitate writing programs and locat¬ 
ing programming errors. The key 
concept—better integration—prevents 
the loss of common state information 
across invocations. Preserving context, 
providing source and version control, 
and developing test suites are vital to 
these integrated environments. 

Users have already seen many such 
improvements in the latest releases of 
QuickBasic, QuickC, C, Pascal, For¬ 
tran, and Masm. The “environmental” 
architecture greatly facilitates program 
development. These languages come 
with many tools, such as Make and Lint 
utilities, and multiple debug features, 
including a separate CodeView debug¬ 
ger. One proposal calls for an SQL type 
of database that will allow all the tools 
in the development environment to 
share a common mode of accessing 
information. The resulting, more com¬ 
plete, integration of the editing, compil¬ 
ing, and debugging process would help 
users produce more reliable programs. 
Better project management is the goal 
here, and the company is considering 
many alternative architectures. 


Microsoft’s languages 

Rather than discuss the other two ses¬ 
sions, interpreter and shared-compiler 
technology, let’s look at the fruits of 
these efforts—the next generation of 
the most popular Microsoft languages. 
We’ll begin with Basic and then take a 
look at C, followed by a discussion of 
the improvements made to the assem¬ 
bler. Finally, in a separate section we 
consider an important issue that has 
received little attention: the ability to 
write programs using a mixed-language 
approach. 


QuickBasic 4.0 

Basic has never been considered the 
language of choice among “serious” 
programmers. Its inclusion with the 
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Quick Basic 4.0 provides multiwindow editing and debugging, as shown here. 


first microcomputer systems with their 
limited memory probably did more to 
hurt its image than to strengthen it. 

This is unfortunate, given that Basic 
was an impressive technological feat for 
that genre of machine. Nonetheless, 
Basic has always been with us and 
nearly everyone turns to it at some time 
or other because it’s so easy to use and 
just right for “quick and dirty” 
solutions. 

Microsoft was the pioneer when it 
came to microcomputer-based Basic 
implementations. Some form of an 
interpreted Basic was included with PC- 
and MS-DOS, and a Basic compiler 
could be purchased as well. The real 
breakthrough came in March 1986 
when the first QuickBasic was released. 

Since that time, Microsoft has 
released a new version of QuickBasic 
about every six months. Version 4.0, 
while following in the footsteps of 
earlier releases, is so superior to any¬ 
thing else that it really rates as a com¬ 
pletely new system. QuickBasic 4.0 
(QB4) features a combined compiler- 
debugger-interpreter in an “Instant 
Environment” that is so fast and so ver¬ 
satile that it meets the needs of both the 
professional and the casual programmer 
alike. 

The instant environment has three 
states: parsed, symbolic, and threaded. 
When you load your program, QB4 
checks syntax and translates the Basic 
statements into a parsed format. To 
interpret a program, QB4 next trans¬ 
lates it from its parsed form to the sym¬ 
bolic state. The final step is the 
translation from symbolic to threaded 
code. On an 8 MHz IBM AT, the state 
change from parsed to symbolic to 
threaded proceeds at about 60,000 lines 
per minute. 

So what happens when you change 
the source code? Generally, if the 
source changes are limited to single 
statements, detranslation occurs from 
threaded to symbolic. Only a few types 
of edits cause it to go all the way back 
to the parsed state. And since the 
threaded to symbolic translation is 
around 150,000 lines per minute, 
Microsoft uses the term “instant” to 
describe this environment. 

QB4 is very fast, both in terms of 
execution and compilation. BC, its 
optimizing compiler, produces code 
that eliminates common subexpressions, 
removes redundant loads, provides con¬ 
stant folding, and supplies 
For . . . Next optimization. Test results 
show that while the object code isn’t as 
fast as that produced by QuickC, the 
speed differential is not critical. 

An important new feature is user- 
definable type and record structures. 


For example, an abbreviated personnel 
record might look like 

TYPE PersonRecord 

LastName AS STRING * 22 
FirstName AS STRING * 12 
MI AS STRING * 1 
END TYPE 

which can then be used in a declaration: 

DIM Persons(50) AS PersonRecord 

so that data can be stored into the 
fields: 

Persons(l).LastName = “Smith” 

and the entire record stored with a Put 
statement using binary I/O: 

OPEN “Personnel.DBF” FOR 

BINARY AS 
PUT #\, BytePosition, Persons(l) 

Also, by using type declarations with 
random I/O, the field statement is no 
longer required. 

Other new features in QB4 include 

• recursion; 

• real functions with local static and 
dynamic variables; 

• subprogram declarations for 
parameter checking; 

• special keywords to support mixed- 
language programming; 

• long integers; 

• subscript ranges from — 32,768 to 
32,767; 


• new functions supporting string 
operations; 

• a “smart” editor that supports 
multiple modules made up of main 
and subprograms, along with a split 
window to view two programs at 
once; 

• a built-in Make facility; 

• better support for IEEE-format 
numbers; 

• additional control-flow con¬ 
structions; 

• dynamic syntactic help; 

• a much improved debugger, pat¬ 
terned after Microsoft’s CodeView, 
that supports an edit and continue 
feature as well as immediate exe¬ 
cution; 

• improved quick library support; 
and 

• better coprocessor support 
to name the most notable. 

Preserved in this latest release of 
QuickBasic is the windowing environ¬ 
ment with its pull-down menus. The 
upper window is called the View win¬ 
dow and the lower, the Immediate win¬ 
dow. Using the Split command, the 
upper window can display two pro¬ 
grams at once. The single top-line menu 
bar now has two more selections than 
the last version. The choices are File, 
Edit, View, Search, Debug, and Calls. 
Unlike the last version, the Alt key now 
toggles so that you need not hold it 
down while selecting from the menu. 

Another new feature extends Help. 
Shift-Fl now displays a summary of the 
syntax appropriate for the command 
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QuickC permits source level debugging, editing, and compiling in an integrated 
environment. 


currently selected by the cursor. Debug¬ 
ging has improved also, with the added 
abilities of executing immediate com¬ 
mands in the Immediate window, trac¬ 
ing more variables, capturing the last 20 
program steps, and selecting the next 
statement to execute. Support for 
CodeView is also provided. 

Users of earlier versions of Quick- 
Basic will, without doubt, find this new 
release to be well worth the modest 
upgrade fee of $25. However, they—as 
well as new users—will not really 
appreciate the full potential of QB4 
until they try it. The new language con¬ 
structs, the rapid translation from 
source to running program, and the 
integrated debugger make this new envi¬ 
ronment as easy to work with as the 
older versions of interpreted Basic and 
BasicA. In fact, with this release there is 
absolutely no reason to continue to use 
interpreted Basic. 

QuickBasic provides an interpreter 
and compiler superior to anything 
Microsoft has offered before. I can 
attest to this as the result of using QB4 
to develop a real-time laboratory system 
for controlling, acquiring, and analyz¬ 
ing human performance data. I found 
that the development took essentially 
half of the time I estimated. Documen¬ 
tation and maintenance improved as a 
result of the ability to modularize the 
source code. Debugging was more rapid 
using the integrated environment, and 
access to all machine resources was on a 
par with C or Masm. In fact, I ended up 
not having to use the mixed-language 
support features because I could man¬ 
age all of our add-in boards from 
QuickBasic without having to use either 
C or Masm. 

In executing programs, the user will 
find a difference between the “com¬ 
piled” code of the QuickBasic environ¬ 
ment and the output of the stand-alone 
BC compiler. What is often overlooked 
in the environment is caught by the 
compiler. I have not found that this 
results in erroneous programs. How¬ 
ever, I was mildly surprised when code 
that seemed to have been debugged sub¬ 
sequently produced error messages. 

QuickBasic will run on an IBM PC or 
compatible with 320 Kbytes of memory, 
DOS 2.1 or higher, and a single floppy 
disk drive. The retail price is $99, 
although as mentioned earlier, the 
upgrade fee is $25 for version 3.0 
owners and $35 for prior versions. 

QuickBasic is truly an outstanding 
buy for both the serious and the casual 
PC user. It is almost addictive—once 
you use it, you will find it hard to revert 
to other languages. As a result, I recom¬ 
mend it unconditionally. 
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QuickC and C version 5.0 

In every endeavor, there must be a 
standard of comparison. When it comes 
to C compilers for the PC, that stan¬ 
dard has been Microsoft’s C production- 
level compiler. Microsoft’s stated goals 
include state-of-the-art core technology, 
increased programmer productivity, 
shared family advantages, early support 
of new operating systems and hard¬ 
ware, and regular updates. 

Version 5.0 of Microsoft’s C com¬ 
piler fulfills all of these goals and pro¬ 
vides a bonus, a new QuickC compiler 
bundled with the package. With shared 
tools, a common runtime system, inter¬ 
language support, and a common 
optimizer and code generator, this latest 
release continues as the standard-bearer 
in the personal computer marketplace. 

The version 5.0 package includes not 
only QuickC, but also CodeView, an 
overlay linker, a library manager, 
numerous utilities (including an excel¬ 
lent Make utility), and an even larger 
runtime library that now contains 
nearly 500 functions (70 of them new). 

A new graphics library has 40 functions 
supporting the basic graphics primi¬ 
tives. Because C and QuickC share run¬ 
time libraries, you have the advantage 
of developing and testing code in the 
Quick environment before using the 
optimizing compiler to get the .EXE or 
.COM form. 

The new compiler features improved 
code generation. The user can specify 
size or speed optimization. In either 


case, informal trials have yielded more 
compact and faster code than with 
previous versions. The combined com¬ 
pile and link command, CL, has more 
options than most of us will ever use. 
With a choice of over forty switches, 
the user can specify the memory model, 
select the floating-point option, control 
the listing and linking process, produce 
debug code, affect the preprocessing of 
the source code, enable language exten¬ 
sions or processor specific code, select 
calling conventions, and so on. 

Microsoft has increased ANSI C 
draft standard support. In addition, the 
company reportedly designed the func¬ 
tions in the runtime library to maintain 
maximum compatibility with both MS- 
DOS and Unix systems. The runtime 
library manual—part of the three- 
manual documentation set—is organized 
alphabetically and describes each func¬ 
tion. An appendix explains the common 
libraries. 

The C language manual in the set 
introduces the elements of C, including 
syntactic and program structure, 
expressions and assignments, state¬ 
ments, functions, and processor direc¬ 
tives and pragmas. Included in the same 
binder are the CodeView, Link, Lib, 
and Make manuals, and a section on 
the utilities that allow you to modify 
files and change the operating envi¬ 
ronment. 

The third manual in the set contains 
the user’s and mixed language guides. 
All of the manuals are extremely well 
done. It is a tribute to this documenta- 
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tion that, with its help, even the inex¬ 
perienced programmer can learn both 
how to write programs and how to get 
them running quickly. 

The new compiler plus utilities and 
runtime libraries might be a rather 
imposing, even overwhelming, set of 
disks and manuals if not for the equally 
well-done setup program that helps you 
with the installation. After you start the 
setup program and answer the questions 
presented, including such items as the 
number and types of libraries (such as 
emulator or coprocessor support), the 
setup program constructs the libraries 
and moves the various files to the 
appropriate disks. While you can run 
with floppies, I would not consider that 
a viable option. I installed the system 
on a hard disk. The end result for me 
was more than three megabytes worth 
of files spread over eight subdirectories. 

The price of the latest version of this 
three-pass, optimizing C compiler is 
$450. That isn’t a bad deal when you 
consider all of its excellent features, 
utilities, documentation, and options. I 
might point out that often these options 
have to be purchased separately when 
you buy other, lower-priced compilers. 
However, if you are upgrading from 
version 4.0, the price is only $75. That 
is less than the retail price of QuickC, 
which is included in the upgrade. How 
can you go wrong? 

Speaking of that, QuickC is an excel¬ 
lent package in its own right. Focusing 
on the process of programming rather 
than the executable program, this 
feature-rich environment makes it easy 
to learn C, to quickly write and debug 
C programs, and to pass the program 
on to its big brother for optimization. 
With the same—and more—fine fea¬ 
tures found in QuickBasic, QuickC pro¬ 
vides a very productive environment. 

QuickC includes a programmer’s 
guide separate from those already dis¬ 
cussed. This manual is pretty good, but 
deals mostly with the QuickC program¬ 
ming environment, getting started, the 
graphics library, and the QuickC 
toolkit. I don’t think you can pick this 
manual up and immediately start pro¬ 
gramming in C if you don’t already 
know the language. Fortunately, the 
manual lists the many excellent texts 
available to help you gain the needed 
understanding. 

If you are seriously considering C as 
your programming language of choice, 
you might as well buy the optimizing 
compiler that can be purchased by mail 
order for a little more than half of its 
retail price. That way you get both the 
quick and optimizing compilers so that 
as your sophistication grows you will 
have a completely compatible growth 


path. Also, you will have the best 
documentation, short of a tutorial book 
on C, to guide you through all the 
things you will need to know about 
writing and compiling C programs. 

The only negative statement I’ve 
heard about the QuickC compiler is that 
it only supports the medium model in 
the windowing environment. Frankly, I 
don’t see this as much of a limitation, 
since all the other models, with the 
exception of the huge model, can be 
used when invoking the compiler from 
the command line. 

System requirements for QuickC are 
a compatible PC, 448 Kbytes of mem¬ 
ory, DOS version 2.1 or higher, and 
two floppy drives. The package costs 
$99 if purchased separately from the C 
compiler. 

There is no question that Microsoft’s 
newest optimizing C compiler, version 
5.0, remains the reigning standard 
against which all other compilers will 
continue to be compared. 
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Fortran 

Fortran is the oldest of the high-level 
languages and still commands a strong 
following, especially among the 
engineering and scientific community. 
Although it is not as popular as some of 
the other languages currently in use in 
the microcomputer marketplace, 
Microsoft has continued to support 
Fortran at a level equal to the more 
widely used languages. 

The most recent release of the Microsoft 
Fortran Optimizing Compiler is Version 
4.0. It offers a number of significant 
improvements over Version 3.3. Ver¬ 
sion 4.0 is a full implementation of the 
ANSI X3.9-1978 language standard, 
and is certified error-free at Full level 
by the General Services Administration. 
In addition, the Microsoft Fortran com¬ 
piler includes a full set of intrinsic func¬ 
tions, including standard IBM VS and 
DEC VAX functions, making the port¬ 
ing of programs from the mini- and 
mainframe environments much easier. 

The program package is shipped on 
seven 5%-inch disks. The first six disks 
include the compiler, the libraries for 
the different memory models, an over¬ 
lay linker, a Make utility, a library 
manager, and the CodeView debugger. 
The seventh disk contains an excellent 
tutorial for the CodeView debugger. A 
number of miscellaneous sample source 
files and utilities also come with the sys¬ 
tem. You can get the package on 
3K-inch disks by simply calling 
Microsoft. 


To install the Fortran system, you 
must use the setup program supplied 
with the package. It is extremely easy to 
use, and similar to the setup programs 
used to install other Microsoft products, 
such as the C compiler and Windows. 

At a number of points during the setup 
process, you can request additional 
information from the program concern¬ 
ing some of the more unusual menu 
selections, such as RAM drive installa¬ 
tion, DOS environment settings, and C 
language compatibility. You can even 
perform a trial run of the setup pro¬ 
gram in which no files are actually 
installed on your system. This can be 
very helpful, especially if you’re lazy 
about reading the manuals before trying 
the installation. 

A number of new features have been 
added to Version 4.0 of the Fortran 
compiler. Three different memory 
models are now supported—medium, 
large, and huge. In the medium memory 
model, each module is given its own 
code segment, total program data is 
restricted to 64 Kbytes, and formal 
array arguments are limited to 64 
Kbytes. The large memory model, the 
default model, is intended for programs 
in which total program code and data 
can each exceed 64 Kbytes. The com¬ 
piler creates multiple code and data seg¬ 
ments as needed. Formal array 
arguments are still restricted to 64 
Kbytes, unless the argument is explicitly 
declared with the “huge” keyword. The 
huge memory model is similar to the 
large memory model, except that for¬ 
mal array arguments are expected to 
exceed 64 Kbytes. Both the medium and 
huge memory models are new to Ver¬ 
sion 4.0 of the compiler. 

The FL command is also new with 
Version 4.0. It combines the compila¬ 
tion process and the linking phase into a 
single command with numerous options 
for performing everything from select¬ 
ing the appropriate floating-point 
library to controlling the format of the 
source program listing. An option 
allows you to specify the type of optimi¬ 
zation you want the compiler to per¬ 
form. The optimization can favor code 
size or program execution time, or 
improve the consistency of floating¬ 
point results. You can select any combi¬ 
nation of these options. You can also 
disable optimization, which can come in 
handy when you use the CodeView 
debugger. 

Microsoft Fortran Version 4.0 sup¬ 
ports three floating-point packages, 
selectable by option switches on the 
compiler command line. Both 8087 and 
80287 math coprocessor support is sup¬ 
plied when the coprocessor is present in 
the system. A software emulation 
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library is also available for both 8087 
and 80287. The emulator package uses 
an 8087 or 80287 if one is present; 
otherwise, it provides many of the 
8087/80287 functions in software. It 
provides the highest degree of accuracy 
aside from the 8087/80287 hardware, 
but is considerably slower. An alternate 
math package is supplied by Microsoft 
for use when execution speed is of para¬ 
mount consideration. It gives you the 
smallest and fastest programs you can 
get without a coprocessor, but results 
are not as accurate as with the emulator 
package. 

A new set of intrinsic functions for 
performing data-type conversion and 
bit manipulation has been added to Ver¬ 
sion 4.0. The three new data-type con¬ 
version functions allow you to convert 
arguments to type Integer *1, Integer *2, 
or Integer *4. The new bit-manipulation 
functions cover such operations as bit 
shifting and the bit-masking operations 
of And, Or, Exclusive Or, and Nega¬ 
tion. Bit set and clear functions are also 
provided. These operations have always 
been prime candidates for assembly lan¬ 
guage library routines, and are a wel¬ 
come addition to the standard set of 
intrinsic functions. 

A Make utility for performing pro¬ 
gram maintenance is supplied along 
with Version 4.0 of the compiler. The 
program is practically identical with the 
Make utility supplied with Version 5.0 
of the Microsoft C compiler, so if you 
have used it with one of the languages, 
it can be used with the other with virtu¬ 
ally no additional learning required. 
Since I began using the Make utility, I 
have not had an occasion to resort to 
using batch files. 

Without question, the most useful 
ancillary program supplied with the 
Fortran compiler is the CodeView 
debugger. I have used CodeView a great 
deal with Version 5.0 of the Microsoft 
C compiler, and felt right at home using 
the debugger with the Fortran compiler. 
It’s in a class by itself among debug¬ 
gers, and can be considered one of the 
main attractions of the Microsoft lan¬ 
guage products. More about CodeView 
will be said later. 

Documentation for Microsoft For¬ 
tran Version 4.0 consists of a user’s 
guide, a language reference manual, a 
CodeView user’s manual, and a quick- 
reference guide. The manuals are excel¬ 
lent in every respect, and I can recom¬ 
mend them for both the novice 
programmer and the experienced 
professional. 

The Fortran compiler requires an 
IBM PC or PC-compatible with DOS 
Version 2.0 or later. At least two floppy 
drives are required, either 3 '/ 2 - or 5/{-inch, 


although I can’t imagine using a high- 
performance compiler such as this with¬ 
out a hard disk. A minimum of 320 
Kbytes of available user memory is also 
required. 
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Masm 5.0 

I suppose it’s hard to get excited 
about an assembler. Years ago that was 
the one piece of software you could 
always expect to find bundled with 
every new machine. Nowadays, as far 
as the PC user is concerned, it is an 
extra cost option that only diehard 
programmers buy. So why the interest? 

The answer is that any serious pro¬ 
gramming will always have a need to 
drop down into the assembler to imple¬ 
ment some feature or function not 
found in a higher level language, or to 
speed up some critical section of code. 
But even if these problems could be 
solved by turning to C or using in-line 
code, an assembler proves useful in 
explaining the limits of the system’s 
architecture. There really is no better 
level than assembler to try something 
out and learn what the machine really 
does. 

Masm, the macro assembler from 
Microsoft, is probably the most widely 
known assembler for the PC. I’m sure it 
captures a large percentage of the mar¬ 
ketplace on brand name recognition 
alone. That might be enough to guaran¬ 
tee its continued sales without signifi¬ 
cant future investment in the product. 
But the company did not stop there. 

New features found in the latest ver¬ 
sion of Masm include 

• assembly using all available PC 
memory, 

• symbol tables up to eight times big¬ 
ger than before, 

• improved speed of assembly (25-40 
percent faster), 


• support for 80386 and 80387 
instructions, 

• new directives for making the con¬ 
struction of program segments eas¬ 
ier, and 

• replacement of Symdeb, the older 
symbolic debug utility, by the 
CodeView debugger. 

Also, the manuals have been extensively 
revised and now come as a set of three 
bound manuals, plus a separate spiral- 
bound reference guide. 

The reference guide includes 8086, 
80286, and 80386 instruction sets as well 
as their coprocessor counterparts for 
the 8087, 80287, and 80387. This 
change reflects the fact that version 5.0 
supports the full 80386 and 80387 
instruction sets as well as 80386 segmen¬ 
tation, automatically generating correct 
code for both 16-bit and 32-bit 
segments. 

The other three manuals consist of an 
excellent programmer’s guide, a mixed- 
language programming guide, and a 
CodeView and utilities manual. Like 
the C programmer’s guide, the Masm 
guide is exceptionally well written and 
can easily serve as a guide to writing 
assembly programs for a user with 
assembler experience on another, com¬ 
pletely different, machine. 

I’ve saved what I consider the best 
for last. It is no secret that program seg¬ 
mentation is a bit more complex for an 
8086 machine. In this latest version of 
Masm, the new directives, including 
Model, Dosseg, Code, Data, and Stack, 
allow you to painlessly achieve the 
necessary segmentation. The Model and 
Dosseg directives define the number 
and types of segments, assign the cor¬ 
rect default attributes for procedures, 
and generate implicit Assume and 
Group statements. The Code, Data, 
and Stack directives automatically pro¬ 
duce the proper segmentation declara¬ 
tions and assign to each its proper 
attributes. 


TITLE 

Sample 


DOSSEG 


; use Microsoft segment 

.MODEL 

Small 

; . . conventions and small model 

.STACK 

256 

; allocate stack space 

.DATA 


; allocate data space 

.CODE 


; procedures go here 

start: 


; label to start at 

END 

start 

; define entry point 


A skeleton for a small model .EXE assembly language program. 
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An abbreviated program using these 
new directives appears in the accom¬ 
panying figure, “A skeleton for a small 
model .EXE assembly language 
program.” 

Minimum system requirements for 
Masm are a PC with 256 Kbytes of 
memory and two floppy drives. Masm 
5.0 costs $150, with upgrade pricing of 
$40 from version 4.0 and $75 from 
earlier versions. With CodeView 
included, the price is rather modest for 
the value received. 
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CodeView 

I’ve mentioned CodeView so many 
times that it seems almost unnecessary 
to describe it in any more detail. Like 
the other new products already discussed, 
CodeView is a powerful, window-oriented 
debugger that you use to track down 
programming errors by tracing through 
a running program. Source code is dis¬ 
played with the line to be executed next 
highlighted. You can then: watch vari¬ 
ables change or take on predetermined 
values; display the output of the running 
program; and perform other debugging 
functions. 

The CodeView window resembles 
those of QuickBasic and QuickC. A 
menu line at the top of the screen allows 
you to select one of nine pull-down 
items: File, View, Search, Run, Watch, 
Options, Language, Calls, and Help. 

There are actually four separate win¬ 
dows, called the display, dialog, regis¬ 
ter, and watch windows. Code appears 
in the display window, while user input 
and system output are presented in the 
dialog windows. The register contents 
appear in the register window, and the 
values or states of “watched” variables 
appear in the watch window. 

CodeView has a built-in language 
interpreter that supports Basic, C, For¬ 
tran, and Pascal. Assembler output can 
be seen between the lines of the higher 
level code. You can evaluate expres¬ 
sions according to the rules of the high- 
level language being debugged. You can 
then store the results in program var¬ 
iables. 

To use CodeView with a higher level 
language requires that the compile and 
link phases be invoked with the 
CodeView switches. The manual that 
comes with CodeView includes a section 
on preparing programs for the debugger 
as well as a thorough explanation of the 
many CodeView options. 

In its latest version, CodeView sup¬ 
ports programs that use overlays and 
library modules. The program works 
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CodeView’s source level debugging capabilities allow you to debug programs in 
multiple languages and to debug programs larger than 640 Kbytes (with EMS 
support). 


with version 4.0 or later of Microsoft’s 
Basic, C, Fortran, and Pascal com¬ 
pilers, and version 5.0 of Masm. With 
Masm, you must use IEEE floating¬ 
point format, and you may not use 
CodeView to debug command programs. 

CodeView comes bundled with the 
full (but not the Quick) compilers and 
the macro assembler. Since the debug¬ 
ger must reside in memory along with 
the program being debugged, you may 
have a problem with too little memory 
available. To get around this problem, 
you can use expanded memory, set up 
the program as an overlaid version, and 
save space by controlling what’s written 
to the symbolic file used during debugging. 

An excellent self-running tutorial 
comes with the Microsoft Optimizing C 
Compiler. The key features of CodeView 
are presented, with the user pacing the 
instruction by tapping the space bar. 
After seeing CodeView in action, I won¬ 
dered why anyone would buy an 8086 
simulator. This powerful tool is not 
only an excellent debugging tool, but a 
learning tool as well. 
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Footnote 

Recently, Microsoft announced new 
versions of the C and Fortran optimiz¬ 
ing compilers, Masm, and the Basic and 
Pascal compilers. Included in the 
announcement was a new “smart” 
programmer’s text editor and an 
enhanced version of CodeView, plus 


other utilities for developing program 
applications. The avowed reason for the 
new versions is to provide combined 
development tools for both MS-DOS 
real mode and OS/2 protected mode 
applications. This is sure to make the 
transition from MS-DOS to OS/2 much 
easier. 


Comments 

I found little to criticize in the 
Microsoft languages and utilities reviewed 
here. About the most significant flaw is 
the choice of shortcut keys used to 
immediately invoke a windowing action 
(such as F3 for repeat last find). The 
chosen keystrokes are not particularly 
memorable. Fortunately, they are dis¬ 
played in the pull-down menus, and 
often a quick-reference card or key¬ 
board template accompanies each prod¬ 
uct. Also, excellent mouse support 
means that you can rapidly move 
between menus and choices without 
ever having to remember what key¬ 
strokes to use. 

All of the Microsoft languages reviewed 
here offer significant improvements 
over their earlier versions. But, in their 
own right, I think they demonstrate 
Microsoft’s avowed commitment to 
developing state-of-the-art products 
with outstanding features, performance, 
and price. No wonder these products 
are the ones owned by professional 
programmers—they are also the ones 
that you should have on your software 
shelf. 
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Microsoft mixed language support 

Daniel McAuliffe, Polhemus Navigation Sciences 


Among the programming languages 
currently in broad use are Basic, For¬ 
tran, C, and Pascal. Each of these lan¬ 
guages offers its own unique features 
and strengths. 

Basic is a good language for begin¬ 
ning programmers, or for those 
individuals interested in developing pro¬ 
grams easy to modify in an interactive 
environment. It has traditionally been 
the first language encountered by nov¬ 
ice programmers, especially those first 
introduced to software in the microcom¬ 
puter environment. 

Fortran is the oldest of the currently 
active high-order languages and con¬ 
tinues to have a strong following among 
the engineering and scientific commu¬ 
nity. It is ideally suited to computation¬ 
ally intensive software of a highly 
mathematical nature. A large body of 
Fortran software is available in the 
form of libraries of mathematical func¬ 
tions and subroutines. In many cases 
the source code for these libraries is also 
available. 

The C language has developed a very 
strong following in the microcomputer 
world. Often referred to as the language 
of the 80s, C is used by many profes¬ 
sional software developers for writing 
compilers and operating systems. Many 
see it as a high-order assembly lan¬ 
guage, adept at performing low-level 
functions. Portability has also been a 
strong selling point for the language. In 
addition, the growing popularity of the 
Unix operating system has boosted the 
number of C programmers. 

Pascal is used extensively in the aca¬ 
demic world as the language of choice 
for teaching the principles of program 
development and algorithm design. It is 
often the first language students 
encounter in which the principles of 
structured programming can be imple¬ 
mented with ease. 

In addition to the benefits offered by 
the unique features of each program¬ 
ming language, the large collection of 
libraries available, especially for For¬ 
tran and C, beg for an efficient method 
of mixed language interfacing. Clearly, 
each language has its place in the soft¬ 
ware community, yet very little mixing 
of programs developed in the different 
languages has taken place. Generally, a 
programmer will translate programs 
from one language to another rather 
than spend the time developing an inter¬ 
face between the languages—with good 
reason. Substantial differences exist 
between the way the different languages 
process information. The three prin¬ 


cipal differences, which make interfac¬ 
ing between the different languages 
difficult, are naming conventions, call¬ 
ing conventions, and parameter-passing 
methods. 

Naming conventions refer to the way 
a compiler assigns names to functions, 
subroutines, or procedures. Basic, For¬ 
tran, and Pascal translate all routine 
names to uppercase. C leaves routine 
names untranslated and adds a leading 
underscore character to the name. The 
length of routine names differs among 
each of the languages. Basic allows up 
to 40 characters per name, Fortran per¬ 
mits only 6 characters, and C and Pas¬ 
cal each allow 8 characters. 

Calling conventions are the methods 
a compiler uses to implement a call to 
another routine. This includes the order 
in which the arguments are passed to 
another function or subprogram, and 
the procedure for returning from a call 
to another routine. 

Basic, Fortran, and Pascal all use the 
same calling convention. Actual 
parameters are pushed onto the stack in 
left-to-right order, that is, the order in 
which they appear in the source code. 
The stack is restored (parameters are 
removed from the stack) by the called 
routine before returning to the caller. 

C calling conventions are quite differ¬ 
ent. C pushes arguments onto the stack 
in the reverse order in which they 
appear in the source code, that is, right- 
to-left. C also requires that the calling 
routine restore the stack after the called 
routine returns. 

The Basic, Fortran, and Pascal call¬ 
ing convention method has the advan¬ 
tage of producing less object code, 
while the C method permits passing of a 
variable number of arguments since the 
first argument is always on top of the 
stack. 

Parameter-passing methods refer to 
how an individual parameter is passed 
to another routine. Microsoft uses three 
methods. An argument may be passed 
by near reference, in which only the 
address offset is passed; by far refer¬ 
ence, in which both the segment address 
and offset are passed; or by value, in 
which case the value of the parameter is 
passed rather than the address. 

By default, Basic passes all 
parameters by near reference. C passes 
parameters by value unless the parame¬ 
ter is an array, in which case the param¬ 
eter is passed by either near reference or 
far reference depending on the memory 
model used. Fortran passes all argu¬ 
ments by far reference by default. Pas¬ 


cal passes arguments declared with the 
keywords VAR and CONST by near 
reference. Parameters declared with 
keywords VARS and CONSTS are 
passed by far reference. All other Pas¬ 
cal arguments are passed by value. 

Given the substantial differences in 
the way Basic, Fortran, C, and Pascal 
interface with each other, how does the 
average programmer overcome these 
differences without resorting to exces¬ 
sive assembly language trickery? 
Microsoft has addressed the problem by 
providing keywords and features in 
each of the languages that allow the 
programmer to change the default con¬ 
ditions for naming conventions, calling 
conventions, and parameter-passing 
methods. The following paragraphs dis¬ 
cuss the Microsoft approach to interfac¬ 
ing between routines written in Basic, 
Fortran, C, or Pascal, and give some 
examples of the new keywords and fea¬ 
tures Microsoft has added to each of 
the languages. 


Basic 

To ease the problem of interfacing 
Basic routines to Fortran, C, or Pascal 
routines, Microsoft has added the 
Declare statement to QuickBasic, Ver¬ 
sion 4.0 or later. The Declare statement 
has two formats: 

DECLARE FUNCTION name 

[CDECL] [ALIAS “aliasname”] 
[arg list] 
and 

DECLARE SUB name [CDECL] 

[ALIAS “aliasname”] [arg list] 

The first form of the statement is used 
for function calls where a return value 
is expected, while the second form is 
used for procedure and subroutine 
calls. In each form of the command, the 
quantity “name” refers to the function 
or subprogram you wish to call, as it 
appears in the Basic source file. The 
optional argument CDECL tells Basic 
that you are calling a C language func¬ 
tion. This directs Basic to use the C lan¬ 
guage name and calling conventions. 
The function name will appear in the 
object file as “_name.” The optional 
argument ALIAS is used if “name” is 
longer than the number of default 
characters allowed for routine names in 
the called language. Basic places the 
actual value of “aliasname” in the 
object file in place of “name.” Each 
element of the optional parameter list 
specifies how the parameter is to be 
passed. 
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The syntax of the parameter list is 

[BYVAL | SEG] variable [AS type].... 

If the BYVAL keyword is used, the 
parameter is passed by value, the 
default for C and Pascal. If the SEG 
keyword is used, the parameter is 
passed by reference, the default condi¬ 
tion for Fortran. “AS type” is used to 
override the type declaration for “vari¬ 
able.” The quantity “type” can be any 
of the keywords INTEGER, LONG, 
SINGLE, DOUBLE, STRING, a user- 
defined type, or ANY. 

As an example, consider the 
statement 

DECLARE FUNCTION Matx% 
CDECL (BYVAL N AS INTEGER, 
K) 

The keyword FUNCTION tells Basic 
that a return value is expected, while the 
keyword CDECL instructs Basic to use 
the C naming and calling conventions. 
This involves inserting the name 
“_matx” in the object file and pushing 
the calling parameters onto the stack in 
the following order: near address of K 
followed by the integer value of N. 

Some restrictions apply in using Basic 
to call C routines. You must use a very 
specific protocol if you want to invoke 
calls to the C function malloc(), for 
instance. You must first reserve a four- 
kilobyte memory block and then locate 
the block in a common area with the 
name NMALLOC. Basic will use this 
memory area to allocate the requested 
memory. Some C functions may not be 
used at all. These include system(), 
spawn(), getenv(), exec( ),and putenv(). 

Note that Basic is unique with respect 
to the way the Microsoft languages 
interface to each other. Because Basic is 
initialized differently than any of the 
other languages, any program that uses 
Basic to call routines in Fortran, C, or 
Pascal must have the main routine writ¬ 
ten in Basic. 


Fortran 

Microsoft Fortran includes a special 
statement for interfacing to routines 
written in Microsoft Basic, C, or Pas¬ 
cal. The INTERFACE statement is used 
to describe the characteristics of the 
function, subroutine, or procedure 
being called. It must appear before any 
call to the routine it describes. If the 
Fortran program is to call a Basic rou¬ 
tine, then the main program must be 
written in Basic with a call to the For¬ 
tran routine. Consider the following 
example of the INTERFACE 


statement: 

INTERFACE TO FUNCTION 

REAL *8 PRINTIT 
[C,ALIAS:’-printit’] (N) 

INTEGER *2 N [NEAR, 

REFERENCE] 

END 

In this example, the keyword FUNC¬ 
TION tells the Fortran compiler that 
the function PRINTIT is to return a 
value of the type REAL *8. The SUB¬ 
ROUTINE keyword can be used in 
place of the FUNCTION keyword if the 
routine does not return a value. The 
optional attribute C, included in the 
brackets, declares that PRINTIT is a C 
language function. This causes the com¬ 
piler to use the C language naming con¬ 
ventions and the C calling conventions. 

Normally, this would cause Fortran 
to truncate the routine name to six 
characters and prefix the underscore 
character before placing the name in the 
object file. However, since the function 
name is longer than six characters, the 
default name length for Fortran, the 
keyword ALIAS is required. When the 
compiler encounters this keyword, it 
will place the string “_printit” in the 
object file in place of the truncated rou¬ 
tine name. The leading underscore is 
required since PRINTIT is a C func¬ 
tion. The function receives a single 
parameter, N, which has both the 
NEAR and REFERENCE attributes. 
These attributes must be specified, since 
by default C functions receive all argu¬ 
ments by value. The C language calling 
conventions replace the Fortran default 
calling conventions because of the C 
attribute used in the INTERFACE 
statement. Default parameter-passing 
methods can be changed by using any 
of the keywords VALUE, NEAR, 

FAR, or REFERENCE in the declara¬ 
tion of the formal parameter. 

Two alternate methods, not involving 
the use of the INTERFACE statement, 
interface Fortran routines to C func¬ 
tions. The first method involves the use 
of the C keyword “fortran” with the C 
function to be called from the Fortran 
routine. The presence of this keyword 
causes the C compiler to use Fortran 
naming and calling conventions when 
compiling the C function. The second 
method involves compiling the C func¬ 
tion with the /Gc compiler switch. This 
has the same effect as the “fortran” 
keyword. 

c 


Microsoft C includes the three key¬ 
words “extern,” “fortran,” and “pas¬ 
cal” to facilitate interfacing to the other 


Microsoft languages. The keywords 
“fortran” and “pascal” are equivalent, 
and can be used interchangeably. Once 
you have declared the Fortran or Pascal 
routine with the appropriate keyword, 
it can be called as if it were just another 
C function. For example, the statement 

extern double fortran matrix(double, 
double) 

tells the C compiler that “matrix” is a 
Fortran function returning a value of 
type double and receiving two argu¬ 
ments, both of type double. When the 
Microsoft C compiler encounters the 
keyword “fortran,” it will use the For¬ 
tran naming and calling conventions to 
generate code for the call to the 
“matrix” routine. 

Microsoft C offers an alternative 
method of interfacing to Microsoft For¬ 
tran or Pascal. The compiler option 
/Gc instructs the compiler to use the 
Fortran/Pascal style of calling and 
naming conventions when generating 
code for the C function. If this option is 
used, the “fortran” and “pascal” key¬ 
words are not required. 

As mentioned previously, no Basic 
routine can be executed unless the main 
program is in Basic. Also, Basic must 
receive all arguments as near references, 
since all data must be in the default 
data segment. 


Pascal 

The primary method of interfacing 
Microsoft Pascal with the other 
Microsoft languages is to use the 
“extern” keyword in a function or 
procedure declaration. For example, the 
statement 

procedure Normal(var i: integer; 

y:real) [C]; extern; 

tells the Microsoft Pascal compiler that 
Normal is an external C language func¬ 
tion receiving two arguments, the first 
of type integer, and the second of type 
real. Pascal will use the C naming and 
calling conventions, that is, the name 
“-normal” will appear in the object file 
and the arguments will be pushed onto 
the stack in right-to-left order. The first 
parameter will be passed by near 
address, because of the keyword “var” 
in the parameter declaration. The sec¬ 
ond parameter will be passed by value, 
the default convention for C and Pascal. 

Microsoft Pascal does not have Basic 
or Fortran keywords similar to the C 
attribute appearing in the brackets, 
because both of these languages use the 
same naming and calling conventions as 
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Pascal. The same restriction that 
applies to calling Basic routines from C 
and Fortran also applies to calling Basic 
routines from Pascal. In fact, for any 
program containing Basic routines, the 
main program must be in Basic. 


Assembly language 

The Microsoft Macro Assembler Ver¬ 
sion 5.0 provides simplified segment 
directives to make interfacing to other 
languages much easier than with previ¬ 
ous versions of Masm. The .MODEL 
directive can be used in place of the 
NEAR and FAR declaration keywords. 
For example, the directive 

.MODEL MEDIUM 

will cause the assembler to automati¬ 
cally generate the appropriate kind of 
return for MEDIUM model programs. 


The .CODE and .DATA directives 
declare code and data segments. These 
can be used in place of the SEGMENT, 
GROUP, and ASSUME keywords from 
previous versions of the macro assem¬ 
bler. Use of the new keyword directives 
also obviates the need for using default 
segment names, such as -TEXT and 
_DATA. In all other respects, interfac¬ 
ing assembly language programs to 
other high-order language programs is 
the same as in previous versions of 
Masm. 


Documentation 

Microsoft has developed a Mixed 
Language Programming Guide for 
programmers who wish to interface 
Basic, Fortran, C, and Pascal routines. 
The quality of the manual is excellent in 
every respect. It contains a separate 
chapter on each of the languages and 


describes in detail the naming conventions, 
calling conventions, and parameter¬ 
passing methods used by the language. 
The chapter for each language contains 
a section on interfacing the language to 
each of the other languages. Numerous 
examples are covered in detail. 


Conclusions 

The new keywords and features that 
Microsoft has added to Basic, Fortran, 
C, and Pascal should make the task of 
interfacing among routines written in 
the different languages much easier. 
The new facilities should open the door 
to truly multilingual programming 
organizations where existing software 
packages can be used with little effort 
and the tedious operation of translating 
large program libraries from one lan¬ 
guage to another is no longer necessary. 



We’re more compatible 










Product notes 

• A version of Simula is available 
for the IBM PC and compatibles 
running under DOS, Xenix, or 
OS/2. The compiler is based on the 
Portable Simula system, previously 
used to implement Simula on several 
mainframes and minis. System 
requirements are 640 Kbytes, a 
numeric coprocessor, and 1.8 
Mbytes of hard disk space. For more 
information contact Simula a.s., PO 
Box 4403 Torshov, Sandakerveien 35 
B, N-0402 Oslo 4, Norway (+ 47 2) 

15 67 10. 


• A scientific laboratory system for 
real-time data acquisition, measure¬ 
ment, and control is available from 
Masscomp, One Technology Way, 
Westford, MA01886, (617)692-5149. 
The underlying hardware is a 
20-MHz 68020 featuring demand 
paging and virtual memory. Soft¬ 
ware includes a real-time implemen¬ 


tation of Unix, Fortran-77, an IEEE 
signal processing library, and Mass- 
comp’s Laboratory Workbench (an 
object-oriented, icon-based package 
that does not require the user to 
write code). Prices start at less than 
$ 20 , 000 . 

• If autorouting is a feature you 
don’t want or need, you can now 
buy smARTWORK from Wintek 
Corporation, 1801 South Street, 
Lafayette, IN 47904, (800) 742-6809 
for only $495. New features in the 
latest revision include EGA and 
VGA support plus no more copy 
protection. Wintek’s HiWIRE pack¬ 
age now handles both schematics 
and printed-circuit layouts. PCBs 
can be up to 60 inches by 60 inches 
with 256 layers, and trace width, 
spacing, and pad shapes are adjust¬ 
able in increments of .001 inches. 
However, HiWIRE does not support 
interactive routing like smART¬ 
WORK, so the user must place the 
traces and pads. 


• A solid synthesis package is now 
available for CADKEY, the 2D/3D 
computer-aided design system that 
runs on a PC. The solids synthesis 
program is fully integrated and com¬ 
patible with CADKEY 3, so the 
modeling process takes place in the 
standard CADKEY environment 
using CADL as the transfer mecha¬ 
nism. Contact Micro Control Sys¬ 
tems, 27 Hartford Turnpike, 

Vernon, CT 06066,(203) 647-0220 
for more information. 

• The next generation of robot con¬ 
trollers featuring an open architec¬ 
ture was announced by Westinghouse 
Electric Corporation. Featuring a 
68000 and a VMEbus configuration, 
the controller is modular and can 
simultaneously operate four process 
control programs with internal 
programmable logic control. You 
can reach Westinghouse at the Wes¬ 
tinghouse Building, Gateway Center, 
Pittsburgh, PA 15222, (412) 
642-3366. 


with the way you work. 


Index Technology is the leader in providing 
CASE solutions. 

Because we work the way you do. 

Instead of forcing a new methodology on you, we 
provide products that can be customized to meet your 
needs. You can work alone or in a group. And you can 
choose the style and technique that works best for you. 

We don’t quit until the job is done, either. Because 
our Excelerator® family of products supports the entire 
development process-from strategic planning to 
analysis and design-even to code generation. 

What’s more, we’re more compatible with the 
hardware and software that work best for developers 
of both MIS and real time systems. Excelerator prod¬ 
ucts run on the IBM PC, DEC VAXstation, SUN and 
Apollo workstations, and link to numerous other 
software programs. 

Call us for a demonstration at 617-494-8244. 

Or write us at Index Technology Corporation, 

One Main Street, Cambridge, MA 02142. 


Index Technology 


® Excelerator is a registered trademark of Index Technology Corporation. 
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NEW PRODUCTS 


PRISM-based Series 10000 brings supercomputing to workstations 


Apollo Computer has announced a 
family of what the company calls per¬ 
sonal supercomputers, based on the 
Parallel Reduced Instruction Set Multi¬ 
processing architecture. PRISM report¬ 
edly features multiprocessing techniques 
and 64-bit architecture. 

The Series 10000 is compatible with 
other Apollo workstations and Apollo’s 
Network Computing System. Configu¬ 
rations feature up to four CPUs, up to 
128 Mbytes of system memory, up to 80 
planes of graphic memory, a 
150-Mbyte-per-second system bus, IBM 
PC AT and VME compatible buses, 
and a scan control resource. Scan path 
technology permits built-in testing of 
VLSI arrays. 

Each CPU has its own integer pro¬ 
cessing unit, floating-point processor, 
cache memory, and memory manage¬ 
ment unit. The operating system han¬ 
dles multiprocessor task management. 
According to the company, shared 
operating system code ensures that each 
free processor selects the next-highest 
priority process from a common ready- 
process queue. 

The RISC instruction set is imple¬ 
mented in hardware. Implemented 
RISC concepts include fixed-length 
instructions, delayed branching, and 
single-cycle execution. 


Disk striping reportedly enables files 
to span multiple drives, allowing high- 
bandwidth access to a file through mul¬ 
tiple controllers. The company supports 
disk striping with ESDI fast actuator 
drives featuring 15M-bit-per-second 
transfer rates. According to the com¬ 
pany, Series 10000 users can stripe two 
or four drives. Users select how many 
and which disks to stripe at initiali¬ 
zation. 

Through Apollo’s operating system, 
Domain/OS, Series 10000 users can 
reportedly run AT&T’s Unix System V 
Release 3, Berkeley Unix 4.3, or both 
simultaneously. 

Configurations available include a 
computational workstation and a 
server. The DSP 10000 compute and file 
server comes with up to four CPUs, 
three gigabytes of disk storage, and 128 
Mbytes of main memory. The DN10000-E 
computational workstation comes with 
one to four CPUs and an 8-bits-per- 
pixel graphics display with 1024 x 800 
resolution that can represent 256 colors 
simultaneously from a palette of 16.7 
million, according to the company. A 
graphics workstation is scheduled for 
the second half of 1988. 

Prices for the server start at $69,900 
for one processor and go up to $129,900 
for four processors. Prices for the com¬ 


putational workstation start at $79,900 
for one processor and range to $139,900 
for four processors. Shipments are 
scheduled for the third quarter of 1988. 

Server: Reader Service 30 
Workstation: Reader Service 31 


DEC offers AI VAXstations 

Digital Equipment has announced 
three artificial intelligence VAXstation 
systems based on the VAXstation 3200 
and 3500 workstations and the VAXsta¬ 
tion 2000 desktop workstation. The AI 
VAXstation 2000, 3200, and 3500 sys¬ 
tems can reportedly be used to develop 
expert systems for delivery on any other 
VAX computer. 

The AI VAXstation systems include 
licenses for VAX Lisp and either the 
Ultrix or VMS operating system with 
associated networking hardware and 
software. A license for VAX OPS5, a 
rule-based expert system development 
tool, is included with VMS systems. 

Both VAX Lisp and VAX OPS5 inte¬ 
grate with VAX C, Fortran, and other 
languages, according to the company. 

The AI VAXstation 2000 workstation 
is packaged for use as a member of a 
local area VAXcluster system. An 
optional cartridge tape drive turns it 
into a stand-alone system. It includes 
six megabytes of memory, a 19-inch 
monochrome monitor, and a 71-Mbyte 
disk drive. 

According to Digital, the AI VAXsta¬ 
tion 3200 and 3500 systems incorporate 
a new CMOS microprocessor that 
delivers Lisp performance 3.5 times 
faster than the MicroVAX II processor. 

The midrange AI VAXstation 3200 
has 15 Mbytes of memory, a 19-inch 
monochrome monitor with four-plane 
gray scale graphics, a 159-Mbyte disk 
drive, and a 95-Mbyte tape drive. 

The AI VAXstation 3500 has 16 
Mbytes of memory, a 19-inch color 
monitor with eight-plane graphics, a 
280-Mbyte disk drive, and a 296-Mbyte 
tape drive. Memory is expandable to 32 
Mbytes. 
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Apollo’s Series 10000 personal supercomputer implements the PRISM architecture. 
The CPU (shown here) incorporates integer and floating-point processing units, 
dual 64-bit caches, and a memory-management unit. 


92 


COMPUTER 











Explorer combines with Apple Mac II for desktop AI 



Texas Instruments’ microExplorer system provides the symbolic processing of an 
AI microprocessor within the Apple Macintosh II system. 


Texas Instruments has announced the 
microExplorer desktop computer for 
artificial intelligence applications. The 
system combines the Explorer AI 
microprocessor and software environ¬ 
ment with the Apple Macintosh II per¬ 
sonal computer. The system reportedly 
results from a value-added-reseller 
agreement between Apple and Texas 
Instruments. 

According to the company, the 
microExplorer incorporates a coproces¬ 
sor board that includes TI’s Lisp 
microprocessor and the Explorer soft¬ 
ware environment. The processor sup¬ 
ports up to 12 Mbytes of memory and 
plugs into a NuBus slot in the Macin¬ 
tosh II. Explorer and Macintosh II 
operating environments reportedly exe¬ 
cute concurrently. 

All microExplorer systems come with 
a runtime version of the Explorer soft¬ 
ware environment for delivery of sym¬ 
bolic processing applications. Explorer 
development software and additional 
memory and mass storage options are 
available, according to the company. 

Prices for microExplorer systems 
start at $14,995. The base configuration 
includes a Macintosh II with two mega¬ 
bytes of memory, a 40-Mbyte disk, 
microExplorer processor with four 
megabytes of memory, and Explorer 


runtime software environment. 

A large configuration with a 21-inch 
monochrome monitor, four megabytes 
of Explorer memory, three 80-Mbyte 
disks, and Explorer development soft¬ 
ware lists for $26,795. 


Owners of Macintosh II systems can 
purchase upgrade kits including the 
microExplorer processor board and sys¬ 
tem software for around $10,000. 
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Motorola adds new models to Delta Series 


Motorola has added the Model 3300 
to the VME Delta Series. According to 
the company, the new Unix-based sys¬ 
tem runs at 4.5 MIPS. It targets the 
open technical systems platform mar¬ 
ket, specifically for low-end image pro¬ 
cessing. In addition, new versions of the 
Model 3600 join the small departmental 
systems family for large workgroup 
computing. 

The VME Delta Series Model 3300 is 
a 68030-based, six-slot VMEbus multi¬ 
user system. The single-board computer 
that drives the 3300 reportedly com¬ 
bines the processing power of the 68030 
at 20 MHz with four or eight Mbytes of 
on-board memory, a 68882 floating¬ 
point coprocessor, an SCSI interface, 
an Ethernet interface, four serial I/O 
ports, and a Centronics interface. 

The Model 3300 supports up to eight 
Mbytes of memory, up to 300 Mbytes 
of disk storage, up to 20 users or asyn¬ 
chronous devices, or connectivity to 96 
users or devices with a DeltaLink con¬ 
troller option. 

Prices for the basic configuration of 


the Model 3300 start at $6995 each in 
quantities of 100. 

The company has added new versions 
of the VME Delta Series Model 3600, 
first introduced in November 1987. The 
68030-based Unix systems target the 
large workgroup systems market, 
according to Motorola. The basic con¬ 
figurations include an MC68030 
microprocessor and an MC68882 
floating-point coprocessor, both at 20 
MHz; four or eight Mbytes of memory; 
four serial ports and a parallel printer 
port; an SCSI interface; and an Ether¬ 
net interface. The systems also come 
with a 150-Mbyte streaming tape drive; 
an 85-, 150-, or 300-Mbyte SCSI Win¬ 
chester disk drive; 11 open VME card 
slots, and three available disk drive 
slots. 

Prices for a 4.5-MIPS Model 3600 
large workgroup platform start at 
$11,895 each in quantities of 60. Ship¬ 
ments are scheduled for June. 

Model 3300: Reader Service 34 

Model 3600: Reader Service 35 



Motorola’s VME Delta Series Model 
3300, which reportedly runs at 4.5 
MIPS, targets the open technical sys¬ 
tems platform market. 
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NCR claims seamless PC integration and transparent 
networking for new System 10000 


NCR has announced the System 
10000, a family of multiuser computers 
that reputedly features seamless per¬ 
sonal computer interfaces and a trans¬ 
parent distributed processing 
environment. According to the com¬ 
pany, the former lets users take advan¬ 
tage of host system files and processing 
power, and the latter allows users in 
multiple locations to run applications 
on any system in the network. 

The new systems use NCR’s 32-bit 
processor and Interactive Transaction 
Executive operating system. They pro¬ 
vide a migration path for NCR’s I- 
Series, according to the company. ITX 
is a multiprogramming operating sys¬ 
tem with interactive, transaction, and 
batch processing capabilities. On the 
System 10000, it reportedly provides 
memory, file, and device management. 
Existing I-Series applications and files 
can be moved to the new family. ITX 
also handles multiple jobs with up to 
eight priority levels. Utilities include 
help, disk cache, automatic spooling, a 
screen editor, a system security pack¬ 
age, and a performance diagnostic 
package. 

The Model 75, the high end of the 
family, reputedly connects up to 1,000 
terminals and was designed to serve as a 
large central system or as a major node 
in a large network. A Model 75 with 
eight megabytes of memory and 1,035 


Mbytes of integrated fixed disk capacity 
costs $226,900. 

The Model 65 connects 760 terminals 
and serves as a base system or as a 
building block within a network. A 
Model 65 with eight megabytes of mem¬ 
ory and 435 Mbytes of integrated disk 
costs $121,700. 

According to the company, the 
Model 65 and Model 75 can accept 
added file and communications proces¬ 
sors, and the Model 65 can be upgraded 
to a Model 75. 

The Model 55 can connect 198 termi¬ 
nals. It serves as a base system or as a 
network building block. A Model 55 
with two megabytes of memory and 270 
Mbytes of integrated disk storage costs 
$48,700. 

The Model 35 connects 16 terminals. 

It was designed as a satellite system. A 
Model 35 with two megabytes of mem¬ 
ory and 135 Mbytes of integrated disk 
costs $31,210. 

NCR claims that incorporation of 
Multibus I and SCSI controllers enables 
the System 10000 to offer a variety of 
clustering and configuration capabili¬ 
ties. Through system clustering, up to 
four systems containing as many as 
eight processors can be linked in a con¬ 
figuration that reputedly offers connec¬ 
tions for 4,000 terminals. 
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IBM plans new AIX/370 
for March 1989 

IBM has announced plans to offer 
AIX for System/370 in March 1989. 

The Advanced Interactive Executive 
operating system is IBM’s implementa¬ 
tion of Unix. 

AIX/370 is a multiuser, multitasking, 
virtual memory, Unix operating system 
for midrange to large systems. It runs as 
a guest under VM/SP or VM/XA SP, 
and can coexist with CMS and other 
guest operating systems such as MVS on 
the same processor. According to the 
company, AIX/370 is designed to con¬ 
form to the proposed IEEE 1003.1 stan¬ 
dard for Posix (portable operating 
system for computer environments). 

One-time charges according to 
processor group are $27,000 for Group 
10, $51,000 for Group 20, $75,000 for 
Group 30, and $144,000 for Group 40. 
Monthly license charges are $3,000 for 
all processor groups. 
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Entry-level Zebra 1620 
supports up to 16 users 

General Automation has announced 
the Zebra 1620 multiuser business com¬ 
puter. The entry-level Zebra is based on 
the 32-bit Motorola MC68020 
microprocessor operating at 12.5 MHz. 
It is software compatible with other 
Zebra models and supports from eight 
to 16 users. 

Zebra 1620 comes with one to two 
megabytes of dynamic memory, 40 or 
67 Mbytes of formatted Winchester 
disk capacity, and a 45- or 60-Mbyte 
%-inch streaming cartridge tape drive. It 
is field-upgradable to a Zebra 1820. 

Enhancement options include 
increased internal memory, additional 
disk capacity, and a higher performance 
MC68020-based CPU. 

Zebra 1620 comes in a desktop enclo¬ 
sure and provides one parallel printer 
port. End users receive a word process¬ 
ing system, Access information 
management and retrieval language, 
Compusheet + spreadsheet, and Accu- 
Plot II business graphics. 

End-user pricing for base configura¬ 
tions starts at $12,500. 

Reader Service 38 



The NCR System 10000 consists of four models: Model 35 (left), the satellite sys¬ 
tem; Model 55, the entry-level system; Model 65, the midrange system; and Model 
75 (right), the high-end system. 
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386-based midrange expands 
Summit Series 

Rexon Business Machines has added 
an 80386-based midrange to the Summit 
Series of multiuser business sytems. The 
Summit 3000 is an IBM PC AT- 
compatible floor-standing tower based 
on a 16-MHz 80386 processor with zero 
wait states. It supports up to 32 users, 
according to the company. 

The base configuration includes the 
processor board, one megabyte of main 
memory, a 12-slot PC AT bus, and a 
300-watt power supply. The processor 
board is slotted for a numeric 
coprocessor. 

Options include memory expansion 
up to six megabytes, a 1.2-Mbyte disk 
drive, power supply upgrades to 900 
watts, a range of terminals and printers, 
60- and 150-Mbyte Wangtek K-inch car¬ 
tridge tape drives, and disk drive 
options. Up to four 5X-inch disk drives 
can be installed for a total disk capacity 
of more than 1.5 gigabytes. 

The Summit 3000 also offers two 
field-installable bus expansion options. 
Users can add a second 12-slot, 16-bit 
PC AT bus or upgrade to a Summit 
4000 by adding a 32-bit VMEbus and 
card cage. 

Rexon systems are sold through origi¬ 
nal equipment manufacturers and 
value-added dealers. Dealer pricing for 
a typical nine-user Summit 3000 with 



Rexon’s Summit 3000 is an 80386-based 
multiuser system compatible with the 
IBM PC AT and targeted at OEMs and 
VARs. 


one megabyte of memory, 178-Mbyte 
ESDI disk drive with 20-ms access time, 
K-inch tape drive, eight serial ports, and 
a 1.2-Mbyte disk drive is $22,510. 

Summit 3000 systems come with MS- 
DOS and can be ordered with SCO 
Xenix 386, Pick Open Architecture, 
Rexon’s Business Basic-compatible 
Recap, or Concept Omega’s Thorough¬ 
bred OS. 
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Program simulates problems 

Causal Systems offers a system simu¬ 
lation software package called SysSim 
for the IBM PC, PC XT, PC AT, and 
compatibles. The product is available in 
two versions. 

The full system version of SysSim 
consists of the Thor array processor and 
the SysSim software. The software fea¬ 
tures a windowing environment and, 
according to the company, requires no 
programming to simulate complex 
problems in any process that requires 
analysis in the frequency/time domain. 
It allows plotting of results, zoom in 
time and frequency, zoom in size, and 
automatic scaling of results. Data can 
be accessed from disk files or A/D con¬ 
verter boards. The Thor array processor 
is based on the AT&T DSP-32 digital 
signal processor. 

The software-only version consists of 
a software package compatible with the 
high-speed version of SysSim. Files 
saved can be accessed by the high-speed 
version without modification. 

SysSim supports the Hercules 
graphics card, CGA, and EGA configu¬ 
rations. A hard disk is recommended. It 
also supports Epson printers. 

SysSim software costs $99. The Thor 
array processor costs $995 ($895 for the 
16-MHz, 8-Mflops version). 
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Force releases 68030-based Focus 32 



The System 32U from Force Computers measures 6.7 X 21.3 X 23.7 inches and 
weighs 88 pounds. 


Force Computers has released a 
68030-based version of the Focus 32 
computer system. According to the 
company, System 32U yields 10 MIPS 
performance, an improvement of 200 
percent over 68020-based models. 

System 32U runs under the Unix 
operating system and VMEPROM, a 
real-time kernel. The system contains 
EPROM, RAM, hard and floppy disk 
drives, tape backup, and communica¬ 
tions ports. The 12-slot backplane has 
seven open slots. 

A basic System 32U includes 
CPU-32, a 25- or 30-MHz engine based 
on the 32-bit 68030 microprocessor; a 
20- or 25-MHz 68882 floating-point 
coprocessor; one megabyte of local 
SRAM with constant zero wait-state; 
four EPROM sockets; two serial ports; 
four megabytes of global system mem¬ 
ory; ISCSI-1, an SCSI host controller 
and floppy disk controller based on a 
68010 microprocessor; ISIO-1, an eight- 
channel multiprotocol serial I/O board; 
a 170-Mbyte SCSI-based Winchester 


disk drive; a one-megabyte floppy disk 
drive; and a 120-Mbyte SCSI-based car¬ 
tridge tape drive. 

System 32U comes with Unix System 
V, Release 3. The transport protocol for 
Ethernet is implemented using TCP/IP. 
VMEPROM-Link, which also comes 
with the system, is a utility that allows 


programs developed under Unix to run 
in the VMEPROM environment. 

System 32U in standard configura¬ 
tion costs $19,900. The price includes 
free VMEPROM and standard Unix 
licenses. 
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IF you are interested as a student, practitioner 
or manager in the growing field of Expert 
Systems... 


I F you want to learn more about the latest practical advances in this new form of 
computer application that can automate and even enhance the ability of human 
experts in diverse fields... 

IF you want to know more about key developmental issues such as higher order 

languages, hardware architecture, verification, system integration, and metrics... 

THEN plan to attend WESTEX-88. , the Third Expert Systems Conference 
June 28 - 30 in Anaheim, California at the Anaheim Marriott. 



FEATURED SPEAKER: Professor Edward Feigenbaum, Stanford 
University , on "Expert Systems: Payoff and Promises” __ 


Invited speakers from universities, industry and government discussing key 
management issues of developing, measuring and controlling expert systems: 


Dr. K.L. Bellman 
Aerospace Corp. 

Dr. Harold Brown 
Stanford University 
Dr. Lee Erman 
Teknowledge 


Michael Fielding 
Perceptronics 
Dr. Steven Hardy 
Teknowledge 
Dr. Michael Buckley 
Rockwell 


Dr. Ed Taylor 
TRW 

Brad Allen 
Inference Corp. 
Dr. Steve Lukasik 
Northrop 


Dr. Peter Friedland 
NASA 

Doug Flaherty 
McDonnell-Douglas 
Dr. James Greenwood 
ADS 


Sessions and papers focusing on issues of interest to practitioners: general use 
and development tools and methodologies and specific expert system applications. 
Parallel tutorials covering basic concepts, advanced concepts and special topics. 


For advance program and registration info., clip and mail to: Westex-88, 8110 Airport Blvd., 
Los Angeles, CA 90045, or call 800-262-4208 (US) or 800-421-6816 (CA) 


Company_ 

Address_ 

City_ 


Please send additional information and registration materials on: 

□ Conference Tutorials □ Conference Sessions □ Exhibits □ 


Registration: 

June 28 Tutorials 
June 29, 30 Sessions 
IEEE Membership #_ 


IEEE Members 

Advance On-Site 
$115.00 $150.00 

$140.00 $180.00 


Non-IEEE Members 

Advance On-Site 
$160.00 $185.00 

$185.00 $230.00 


ADVANCE REGISTRATION DEADLINE June 10,1988 ' 
Sponsored by the IEEE Los Angeles Council 


















Membership Application 


HOW TO JOIN 


Membership dues and publication subscriptions are annualized to December 31. 
Pay the full-year fee if application is mailed September 1-February 29. 

Pay the half-year fee if application is mailed March 1-August 31. 


I COMPUTER SOCIETY ONLY (affiliate membership). 

I You are eligible if you are seriously interested in any aspect of the 
computer field or if you are a member of one of the affiliate 
societies listed below. 

(Check all applicable societies.) Man-Aug3i sepn-Febag 


Affiliate Societies 


..□$19.50 □ $39.00 


□ American Institute of Aeronautics and □ Instrument Society 

Astronautics (AIM) : O Mathematical Assc 

□ American Institute ol Physics (AIP) g Na || ona | Associate 

□ American Mathematical Society (AMS) D operations Resear 

f □ American Society ot Mechanical Engineers (ORSA) 

: □ Association for Computing Machinery (ACM) □ Society of Aircraft f 
[ □ Australian Computer Society (SAMPE) 

1 □ British Computer Society 
> □ Data Processing Management Association 
(DPMA) 

l □ Information Processing Society of Japan (IPSJ) 

□ Institute of Electronic, Information and 
r Communication Engineers (IEICE) of Japan 
I. □ Institution of Electrical Engineers (IEE-UK) 


:h Society of America 


Mathematics (SIAM) 

□ Society for Computer Simuli 

□ Society for Photo-Optical Ins 
Engineers (SPIE) 

□ The Computer Society of th« 


( COMPUTER SOCIETY MEMBERSHIP FOR 
IEEE MEMBERS. If you are presently an IEEE member, you 
may join the Computer Society for a nominal amount. (Complete 
only shaded area of application.) 


IEEE Member Number _ 


Mar 1-Aug 31 Sept 1-Feb 29 

□ $7.50 □ $15.00 


OPTIONAL PUBLICATIONS 

4 Whichever membership option you chose, you are now eligible to 
subscribe at low member rates to these periodicals. 


) COMPUTER SOCIETY AND IEEE . In addition to your 
■ Computer Society benefits, you’ll receive many IEEE privileges 
and benefits. You are eligible if your technical interests are in 
computer science and engineering, the electrical and electronics 
fields, or related fields. Your entry membership grade will be 
determined by your level of participation, contributions, education 
and/or experience in those fields. 


IEEE Computer Graphics & Applications (3061) .. 
IEEE Design and Test (3111) 

IEEE Expert (3151). 

IEEE Micro (3071) 

IEEE Software (3121). 

Transactions on Computers (1161) 

Transactions on Pattern Analysis and 

Machine Intelligence (1351). 

Transactions on Software Engineering (1171). 


Feb 29 

' □ $ 9.50 □ $19.00 

q $10.00 □ $20.00 
□ $6.00 □ $12.00 

□ $9.00 □$18.00 

□ $ 8.50 □ $17 
- © $ 9.00 n$18 


Residence 

[ United States.. .. 
Canada. 

' Latin America.... 
Asia, Pacific. 


Mar 1-Aug 31 Sept 1-Feb 29 

..□$41.00 □$82.00 
.. □ $38.60 □ $77.00 

.. □ $39.00 □ $78.00 

U $33.50 □ $67.00 

□ $34.50 □ $69.00 


□ American Express 
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Microsystem Announcements 


Company, Model, Function_Comments R.S. No. 


Amdek 
Laserdek 1000 
CD-ROM drive 


Apple Computer 
AppleCD SC 
CD-ROM drive 

benchMark Technologies 
bRISC 

Single-board computer 

Digital Electronic Systems 
Fastdisc 

Electronic disk drive 


DSP Design 
SV25 

Processor board 


Heurikon 

HK68/V2E 

Single-board computer 


ICS Electronics 
Model 4814 
IEEE-488 bus interface 


Industrial Computer Source 

7170,7171 

Industrial computers 


Mitel Semiconductor 
MH89500 
R-interface module 


Nth Graphics 
Nth 3D Engine 
Display controller 


Val-Tech 

vtl088 

Single-board computer 


Xycom 
XVME-650 
VMEbus CPU module 


An internal half-height CD-ROM drive for IBM PCs and compatibles. Stores 552 Mbytes 
per CD. Operates off the PC’s power supply. Comes with interface card, device driver, 
cable, audio software, MS-DOS CD-ROM extensions, a CD cartridge, a headphone jack, 
and a user’s manual. Cost: $895. 

A CD-ROM drive for Macintosh and Apple II computers. Stores 552 Mbytes per CD. Fea¬ 
tures a 64-Kbyte memory buffer, SCSI, an audio chip set, desk accessory software, a head¬ 
phone jack, two RCA audio jacks, and a universal power supply. Cost: $1,199. 

A VME-based single-board computer on a 6U Eurocard, featuring the Intergraph Clipper 
CPU. Available with a 33-MHz Clipper CPU and designed to accept a 50-MHz Clipper. 
Provides up to 16 Mbytes of RAM per board. Cost: £4,000 for a 4-Mbyte C100 board 
(OEM quantities). 

A RAM-based electronic disk drive with constant data backup to a mechanical disk. Fea¬ 
tures an access time of .02 ms, data transfer of 40 Mbps, memory expandable from 
15.8-591 Mbytes, SCSI, backup power, and shadow disk option. Cost: starts at $4,875; 
$1,056 for additional 4-Mbyte boards, $6,390 for 16-Mbyte boards. 

An STE bus processor board based on the 8086 code-compatible V25 microcontroller from 
NEC. Runs at 8 MHz. Offers two RS-232 serial ports, 24 digital I/O lines, two 16-bit 
programmable counters/timers, dual-channel DMA controller, programmable interrupt 
controller, watchdog circuit, and optional real-time clock. No price given. 

A 32-bit, single-board VME microcomputer for real-time applications. Has up to 25-MHz 
68020 CPU, 4 or 16 Mbytes of DRAM, up to 2 Mbytes of EPROM, VSB memory expan¬ 
sion bus, four RS-232 serial I/O ports, and one Centronics-compatible parallel port. Cost: 
$4,295 for 4-Mbyte board. 

An OEM card that provides an RS-232 or RS-422 interface to the IEEE-488 bus as a con¬ 
troller or device. Includes 115/230V AC power input and various mechanical mounting 
options. Offers flexible formats with a wide range of baud rates. Cost: $450 in OEM quan¬ 
tities. 

Rack-mounted industrial computers compatible with IBM’s 7532 computer. The 7170 is a 
16-bit system using Intel’s 12-MHz 80286 processor and optional 80287 math coprocessor. 
The 7171 is a 32-bit sytem using Intel’s 80386 at 16 MHz with an optional 80387 and 2-4 
Mbytes of RAM. Cost: $3,995 for 7170; $5,595 for 7171-2 and $6,195 for 7171-4. 

An ISDN R-interface rate adaption device. Compatible with V.24, X.20, X.20 bis, X.21, 
and X.21 bis. Rate adapts these terminal interfaces into 64 Kbps B channels in compliance 
with CCITT 1.461,1.463, V.110, and ECMA.102. Handles synchronous and asynchronous 
data terminal equipment with selectable data rates from 50 bps to 64 Kbps. Sampling starts 
in May. Cost: $36 (5,000s). 

A 3D display controller board for the IBM PC AT. Combines parallel processing architec¬ 
ture and hierarchical management of the graphics display list. Comes with 1 Mbyte of 
video RAM, 2 Mbytes of display list RAM, and drives hi-res monitors with 1,024 x 768 
pixels and a 60-Hz refresh rate. Displays 256 colors from a palette of 4,096 (expandable to 
16 million). Cost: $5,995. 

A CMOS, STEbus, single-board computer engineered for ROM-based applications. 
Includes a 5-MHz 80C88 CPU and 82C85 clock generator. Also features a programmable 
interrupt controller, a real-time clock/calendar, a watchdog timer, STEbus system con¬ 
troller functions, and on-board 32K x 8 CMOS EPROM with 8K x 8 CMOS SRAM. No 
prices given. 

A 32-bit VMEbus CPU module designed around the National Semiconductor 32332 CPU. 
Runs at 15 MHz and provides a floating-point coprocessor, a memory management unit, a 
timing control unit, and an interrupt controller. Features local memory of 1-4 Mbytes of 
DRAM and two 32-pin Jedec memory sites. Available in the third quarter of 1988. No 
price set. 
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1C Announcements 


Company, Model, Function_Comments_RS. No. 


Advanced Micro Devices 
Am29C327 

Floating-point processor 


Dense-Pac Microsystems 
DPE45128, DPE51288 
EEPROM modules 


Integrated Device 
Technology 
IDT71502 
SRAM 

Motorola 

68000 enhancements 
CPUs 


Motorola 

MCM6264J, MCM6290J 
SRAMs 


National Semiconductor 
GAL16V8, GAL20V8 
GAL devices 


Texas Instruments 
SN74ACT8847 
Floating-point processor 


Texas Instruments 

TIBPAD16N8-7 

PAD 


Valtronic Technology 
64K x 8 45-ns SRAM 
Memory Module 

Vitesse Semiconductor 
VS8001; VS8002 
Multiplexer; demultiplexer 

Weitek 

WTL 3364, WTL3164 
Floating-point processors 


Weitek 

WTL 2364; WTL 2365 
Floating-point chip set 


A 64-bit, 1.2-^m, CMOS floating-point processor that supports IEEE-754; DEC D, F, and 
G; and IBM floating-point formats. Features a 100-ns throughput rate. Performs arith¬ 
metic and logical operations on 32- and 64-bit integers. Includes more than 70 instructions. 
Comes in a 169-lead PGA. Cost: (100s) $595 for 100 ns, $395 for 120 ns. 

The DPE45128 contains 16 32K x 8 EEPROMs in LCCs, two decoders, three buffers, and 
a data transceiver on a 48-pin ceramic DIP. The DPE51288 is a 128K x 8 EEPROM with 
four 32K x 8 EEPROM devices and a decoder on a 32-pin ceramic substrate. Prices vary 
according to speeds and grades. 

A 4K x 16 CMOS static RAM featuring high-speed registers at the RAM outputs, IDT’s 
Serial Protocol Channel, and a 35-ns address access time. The SPC feature can be con¬ 
figured as a diagnostic register. Available in a 48-pin plastic and sidebrazed DIP and a 
52-pin plastic LCC. Cost: $44 (100s) for 48-pin plastic. 

Faster versions of 68000 family CPUs: a 33-MHz 68020, a 16-MFlz 68000, a 16-MHz 
68HCOOO in a plastic DIP, and a 25-MHz 68030. The 68HC000 is a low-power-dissipation 
version of the 68000 chip. Cost: (100-499) $571 for 68020, $34.45 for 68HCOOO, $18.90 for 
68000, $485 for 68030. 

The MCM6264J is an 8K x 8 static RAM that comes in 35-ns ($22.13 in 100s) and 45-ns 
($13.69 in 100s) versions. The MCM6290J is a 16K x4 static RAM that comes in 25-ns 
($25.12 in 100s), 30-ns ($17.39 in 100s), and 35-ns ($15.46 in 100s) versions. Both are avail¬ 
able in small-outline J-lead packages. 

A new family of generic array logic devices featuring maximum operating power supply 
from 45-90 mA, maximum access times from 15-35 ns, and eight output-logic macrocells. 
GAL16V8 can emulate 20-pin programmable logic arrays, while GAL20V8 can emulate 
24-pin PALs. Cost: ranges from $3.75 to $10.35 (100s). 

A one-^m EPIC CMOS device that performs 33 Mflops in single- and double-precision 
operations. Combines floating-point multiplier and a floating-point arithmetic logic unit. 
Features three-port architecture and 64-bit internal bus structure. Operates from 0°-70°C. 
Comes in a 209-pin PGA. No prices given. 

A seven-nanosecond programmable address decoder that is pinout compatible with the 
16L8 PAL architecture. Contains 10 dedicated inputs and 8 product terms, each followed 
by an inverting buffer. Operates from 0°-70°C. Comes in a 20-pin, 300-ml plastic DIP and 
20-pin PLCC. Cost: $9.39 (1,000s). 

A 64K x 8 static RAM memory module with access time of 45 ns (available at other 
speeds). Comes in a 34-pin SIMM. Measures 0.75 inch by 3.5 inches. Operational voltage is 
5V. Also comes 64Kx9. Cost: about $60 (10,000s). 

The VS8001 is a 1.25-GHz, GaAs, 12-to-l multiplexer. The VS8002 is a GaAs l-to-12 
demultiplexer. Both have ECL-compatible I/O and a self-test path to test each other. They 
come in 52-pin leadless and leaded chip carriers and operate from standard ECL power 
supplies. Cost: (1,000s) $320 each for VS8001L-12 and VS8002L-12. 

Both have a 64-bit floating-point multiplier, a 64-bit floating-point ALU, a divide/square- 
root unit, a 32-word by 64-bit six-port register file, and status and control logic. They oper¬ 
ate at a peak rate of 20 Mflops for the 100-ns speed grade. The 168-pin WTL 3364 has 
three 32-bit ports; the 144-pin WTL 3164 has one 32-bit bidirectional bus. Now sampling. 
Cost: $829 (10s) for WTL 3164. 

A 64-bit, CMOS chip set that implements the IBM-370 Basic Floating-Point Facility stan¬ 
dard. Consists of the WTL 2364 multiplier and WTL 2365 ALU, capable of up to 16 
Mflops for double-precision operations. Samples are available now, in speeds of 60 ns and 
75 ns. Deliveries in June. Cost: (1,000s) $700 for 75-ns and $825 for 60-ns versions. 
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CAREER OPPORTUNITIES 


RATES: $12.00 per line, $120 mini¬ 
mum charge (up to ten lines). Average six 
typeset words per line, nine lines per 
column inch. Add $10 for box number. 
Send copy at least one month prior to 
publication to: Heidi Rex or Marian 
Tibayan, Classified Advertising, COM¬ 
PUTER Magazine, 10662 Los 
Vaqueros Circle, Los Alamitos, CA 
90720; (714) 821-8380. 

In order to conform to the Age Discrimi¬ 
nation in Employment Act and to dis¬ 
courage age discrimination, COMPUTER 
may reject any advertisement containing 
any of these phrases or similar ones: 
“...recent college grads...,” “...1-4 years 
maximum experience...,” “...upto 5 years 
experience...,” or “...10 years maximum 
experience. ” COMPUTER reserves the 
right to append to any advertisement, 
without specific notice to the advertiser, 
“Experience ranges are suggested mini¬ 
mum requirements, not maximums.” 
COMPUTER assumes that, since adver¬ 
tisers have been notified of this policy in 
advance, they agree that any experience 
requirements, whether stated as ranges or 
otherwise, will be construed by the reader 
as minimum requirements only, 


THE PENNSYLVANIA STATE 
UNIVERSITY 
Computer Engineering 

Applications are invited for tenure-track 
and visiting faculty positions at all levels. 
Candidates from all areas of computer engi¬ 
neering (hardware and software) will be con¬ 
sidered. The Computer Engineering Pro¬ 
gram at The Pennsylvania State University is 
within the Department of Electrical Engi¬ 
neering which has over 50 faculty members, 
and approximately 1500 undergraduate 
majors, 170 graduate students. Candidates 
should have a Ph.D. in Electrical/Computer 
Engineering or related areas. There are 13 
faculty members within the Computer Engi¬ 
neering Program. Excellent instruction and 
research computing facilities are available 
within the Department, College and at the 
University Computing Center. 

Please send your letter of application, 
resume, or inquiries, together with three 
references to: T. Feng, Computer Engineer¬ 
ing Program, Department of Electrical Engi¬ 
neering 129 Electrical Engineering East, Box 
ES, The Pennsylvania State University, 
University Park, PA 16802. 

Deadline for applications is June 30, 1988 
or until suitable qualified candidates are 
selected. “An Equal Opportunity/Affirmative 
Action Employer.” 


SHIP ANALYTICS, INC. 

Senior Electronics Systems Engineer 

SHIP ANALYTICS, INC. has an im¬ 
mediate full-time opening for a Senior Elec¬ 
tronics Systems Engineer in our Commercial 
Systems Division. We are an established 
leader in marine simulators and computer 
graphics. 

Candidates will have a B.S. degree in elec¬ 
trical engineering or equivalent with a 
minimum of two years industrial experience in 
hardware and software design and develop¬ 
ment of marine real-time computer simulation 
systems. Knowledge of FORTRAN and As¬ 
sembly Language 8051 is required. Ex¬ 
perience in hardware and software design and 
development of real-time computer simula¬ 
tion systems is essential. Your assignments as 
a team project member for research and de¬ 
velopment activities in specification, design, 
development, evaluation, and modification of 
hardware/software will be challenging. Sal¬ 
ary: $53,500. We are an equal opportunity 
employer M/F/V/H. 

Send resume to: Job Service Technical 
Unit, Connecticut Department of Labor, 200 
Folly Brook Boulevard, Wethersfield, Con¬ 
necticut 06109. Refer to Job Order *3007229. 


UNIVERSITY OF ALBERTA 

Department of Computing Science 

Applications are invited for two tenure- 
track positions at the Assistant/Associate Pro¬ 
fessor level. Responsibilities include research 
as well as teaching at the graduate and under¬ 
graduate levels. Strong candidates from all 
research areas will be considered, but areas of 
special interests include database systems, 
VLSI/computer architecture, operating 
systems, numerical analysis and computer 
graphics. 

The Department consists of 36 academic 
and 28 support staff. Current hardware sup¬ 
port includes an Amdahl 5870, a network of 
four VAX 11/780’s and about thirty Sun 
Workstations, and well-equipped microcom¬ 
puter and workstation laboratories for 
graphics, VLSI, and A1 research. Access to a 
Cyber 205 is available. 

Salary range $32,756 to $57,236 and is 
commensurate with qualifications and ex¬ 
perience. Send curriculum vitae and the 
names of three references, and up to three 
reprints or copies of important publications. 
New Ph.D.’s should also include a copy of 
their transcript. Apply to: 

Dr. Lee J. White, Chairman 
Department of Computing Science 
University of Alberta 
Edmonton, Alberta. Canada 
T6G 2H1 

Applications will be accepted until June 30, 
1988. 

The University of Alberta is committed to 
the principle of equity in employment. 


STATE UNIVERSITY OF NEW YORK 
AT BINGHAMTON 
Data Base and Theoretical 
Computer Science 

The Department of Computer Science of 
the State University of New York at Bingham¬ 
ton seeks applicants to fill an anticipated posi¬ 
tion in a dynamic and growing Department. 
Prefer associate or full professor level with pro¬ 
ven expertise in data base systems and a 
strong orientation toward theoretical com¬ 
puter science. Assistant professor or a long 
term visiting appointment may be considered. 

The Department offers programs leading to 
the B.S., M.S., and Ph.D. degrees. High 
technology computer-oriented companies in 
the local area, such as IBM, GE, Singer-Link, 
and Universal Instruments, provide oppor¬ 
tunities for professional development both on 
and off campus. 

Nominations or applications should be sent 
to Dr. Thomas F. Piatkowski, Chairman, 
Department of Computer Science, the 
Thomas J. Watson School of Engineering, 
Applied Science, and Technology, SUNY- 
Binghamton, Binghamton, NY 19301; (607) 
777-4803; tfp@bingvma.bitnet. 

SUNY is an equal opportunity affirmative 
action employer. 


UNIVERSITY OF MISSOURI-ROLLA 
Faculty Positions in 
Artificial Intelligence 

The University of Missouri-Rolla has two 
openings in the Department of Electrical 
Engineering for faculty with a research and 
teaching interest in Artificial Intelligence. 
Specific areas of interest include natural 
language processing, neural networks, real¬ 
time knowledge-based system design, intelli¬ 
gent sensor fusion development, and infer¬ 
ence engine design. The successful candidate 
will participate in the Intelligent Systems 
Center at UMR where they will work on inter¬ 
disciplinary research projects funded by the 
government and private industry. Faculty are 
expected to develop an externally-funded 
research program utilizing center resources 
which include a SUN/APOLLO Network, 
Software Engineering professionals and 
technical research support staff. A SUN 
4/110 or equivalent will be made available to 
each successful candidate. The positions re¬ 
quire a Ph.D. degree in either EE, Computer 
Engineering, Math, or Computer Science. In¬ 
terested applicants should send a detailed 
resume with a list of three references to Dr. 
Walter Gajda, Chairman, Department of 
Electrical Engineering, University of Missouri- 
Rolla, Rolla, MO 65401. Applications will be 
accepted until the positions are filled. UMR 
is an Affirmative Action/Equal Opportunity 
Institute. 
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NAVAL POSTGRADUATE SCHOOL 
Position Announcement in 
Computer Science 

The Department of Computer Science has 
immediate openings for faculty positions at all 
levels. Our primary interests are in the areas of 
operating systems, distributed systems, pro¬ 
gramming languages, and algorithms. Our 
secondary interests are in the areas of process¬ 
ing of visual data, real-time systems, and soft¬ 
ware engineering. An applicant should have a 
PhD in Computer Science or a related field 
and have a strong interest in both graduate 
teaching and research. Senior applicants must 
have distinguished research records. Appoint¬ 
ments can begin at any time during the year. 

The Department offers MS and PhD 
degrees in Computer Science. Departmental 
facilities (supported by 9 full-time computer 
professionals) consist of six instructional and 
research laboratories including the Database 
Systems Laboratory, the Graphics and Video 
Laboratory, the Software Engineering Labo¬ 
ratory, the Microcomputer Systems Labora¬ 
tory, the Artificial Intelligence Laboratory and 
the Computer Science Academic Laboratory. 
In these laboratories are the latest, state-of- 
the-art computing equipment including LISP 
machines, high-performance graphics work¬ 
stations, bit-mapped graphics workstations, 
multi-microprocessor systems, etc. During the 
academic year, the faculty normally teach for 
two quarters and conduct full-time research 
supported by major research programs in both 
the Department of Defense and the non-DOD 
organizations during the other two quarters. 
New faculty receive initial support from an on- 
campus research foundation. 

Located on Monterey Bay, the areas of 
Monterey, Pebble Beach, and Carmel pro¬ 
vide a pleasant Northern California coastal 
climate and easy access to Silicon Valley com¬ 
panies and universities. 

Please send a detailed resume and three 
letters of reference to: 

Search Committee 

Computer Science Department (Code 52) 
Naval Postgraduate School 
Monterey, CA 93943 
Tel. No. (408) 646-2449 

AN EQUAL OPPORTUNITY/ AFFIRMA¬ 
TIVE ACTION EMPLOYER. 


KNOX COLLEGE 

Mathematics and Computer Science 
Galesburg, Illinois 61401 

Tenure track position in the Department of 
Mathematics and Computer Science for a 
computer scientist. A Ph D. in Computer 
Science or related discipline required. Duties 
include teaching all levels of undergraduate 
computer science. The teaching load is two 
courses per term for each of three terms. 
Salary and rank are dependent on qualifica¬ 
tions and experience. Knox is a selective 
liberal arts college. Applications from women 
and minorities are strongly encouraged. Send 
vita, transcripts, and three letters of recom¬ 
mendation to Dennis M. Schneider, Chair. 


INTERNATIONAL COMPUTER 
SCIENCE INSTITUTE 
Berkeley, California 

The International Computer Science In¬ 
stitute seeks applicants for research and staff 
positions for its growing program in funda¬ 
mental Computer Science research. The ini¬ 
tial focus of the Institute is on massively parallel 
computation with subgroups addressing the 
theory, scientific applications and realization of 
massive parallelism. Candidates for research 
positions should have a demonstrated record 
of achievement suitable for a faculty appoint¬ 
ment at a research university. Both junior and 
senior level positions are being filled. Support 
staff applicants should have a record of suc¬ 
cess in an advanced research environment. 

The Institute occupies a newly designed 
14,000 square foot laboratory just off the cen¬ 
tral UC campus in downtown Berkeley. It is 
independent of the University of California but 
has strong ties with some of its faculty and 
students. Address inquiries to: 

Jerome A. Feldman, Director 
International Computer Science Institute 
1947 Center St., Suite 600 
Berkeley, CA 94704 
ICSI is an Equal Opportunity Employer. 


BROWN UNIVERSITY 
Announcement of a Faculty Position 
in the Electrical Sciences 

The Division of Engineering of Brown 
University announces a tenure-track position 
in Electrical Engineering starting in January 
1989. The appointment will be made at the 
Assistant Professor level. Applications are 
sought from candidates with a Ph. D. or equiv¬ 
alent degree in Electrical or Computer Engi¬ 
neering. The applicant is expected to conduct 
and publish high-quality research in one of the 
core areas of Computer Engineering such as 
parallel, distributed, high-speed, or algorithm- 
driven architectures, operating systems, com¬ 
puter networks, or CAD. 

The appointee should have a strong com¬ 
mitment to teaching at both the graduate and 
undergraduate levels. He or she will have im¬ 
mediate access to equipment and support staff 
of the Laboratory for Engineering Man/ 
Machine systems (LEMS) and close inter¬ 
action with the five current LEMS faculty in 
the area of intelligent machines. LEMS is a 
dynamic focus for computer engineering to 
facilitate theory and practice in a cooperative 
interdisciplinary research environment. The 
appointee will be expected to teach courses 
on digital circuits and computer architecture, 
other topics in the area of computer engineer¬ 
ing, and participate in the teaching of the 
undergraduate core engineering curriculum. 
Applications consisting of a resume and 
names and addresses of three references 
should be submitted to: 

Professor Harvey F. Silverman 
Chairman, Search Committee 
Division of Engineering 
Box D 

Brown University 
Providence, RI 02912 

The deadline for submission is June 30, 
1988. Brown University is an Equal Oppor¬ 
tunity Affirmative Action employer. 


COLORADO STATE UNIVERSITY 
Chairperson 

Colorado State University invites applica¬ 
tions for the position of Chairperson of the 
Department of Computer Science. Candi¬ 
dates for this position must have a Ph.D. or 
equivalent and a distinguished record of re¬ 
search and scholarship in computer science or 
related field. The department is particularly in¬ 
terested in locating an individual with the 
desire and ability to administer a dynamic, 
growing department. 

Colorado State University is located in Fort 
Collins, Colorado, an attractive community of 
about 86,000 people, located 65 miles north 
of Denver along the front range of the Rocky 
Mountains. Fort Collins has a clear, dry cli¬ 
mate and mild temperatures. 

Total enrollment at Colorado State Univer¬ 
sity is about 18,000 regular, on-campus stu¬ 
dents. The Computer Science Department 
has 600 undergraduate majors, and 70 grad¬ 
uate students in its MS and Ph.D. programs. 
The department has a faculty of 11 actively 
engaged in research and teaching, plus 
several instructors and support staff. The 
department maintains strong professional ties 
with local industry and intends to expand 
these relationships with the help of the new 
department chairperson. 

Department computing facilities include a 
Sequent 21000 with 16 processors, 4 DEC 
minicomputers, 9 HP minicomputers, and 
numerous Sun workstations, all of which run 
Unix and are fully networked. A distributed 
computing laboratory comprises four ATT 
3B2/400 computers networked with 24 ATT 
Unix PC’s. Campus facilities include two CDC 
835 mainframes and a CYBER 205. 

Send a resume (including names and ad¬ 
dresses of at least three references) or letter of 
nomination to Dr. Duane Boes, Chairman, 
Search Committee: College of Natural Sci¬ 
ences; Colorado State University; Fort Col¬ 
lins, CO 80523. (boes@euler.colostate.edu) 

This position will remain open until an ac¬ 
ceptable candidate is found. The search com¬ 
mittee will begin reviewing applications on 
October 31, 1988. 

Colorado State University is an EEO/AA 
employer. Equal Opportunity Office: 314 
Student Services Bldg. 


THE CATHOLIC UNIVERSITY 
OF AMERICA 

COMPUTER SCIENCE: Applications are 
invited for a tenure track position at the assis¬ 
tant professor level starting in the 1988-89 
academic year. The deadline for applicant is 
July 1, 1988 or until appointment is filled. 

Candidates must have a Ph.D., and a com¬ 
mitment to computer science education and 
demonstrated research ability in computer 
science. The candidate will play an active role 
in the development of the program. Send 
resume and three references to: Dr. Mario 
Casarella, Search Committee Chairman, 
Computer Science Program, 201 Pangborn 
Hall. The Catholic University of America, 
Washington, D.C. 20064. An Equal Oppor¬ 
tunity/Affirmative Action Employer. 


May 1988 


101 








THE UNIVERSITY OF ALABAMA 
IN HUNTSVILLE 

The Electrical and Computer Engineering 
Department of The University of Alabama in 
Huntsville (UAH) announces the establish¬ 
ment of an Eminent Scholar Chair in Com¬ 
puter Engineering and invites applications and 
nominations for the position. 

The professorial chair is endowed through 
contributions from anonymous donors and 
the State of Alabama. The successful can¬ 
didate will be granted tenure on the initial ap¬ 
pointment and will be given a reduced teach¬ 
ing load, research and secretarial assistance, 
and a salary commensurate with qualifica¬ 
tions. The position is available beginning 
September 1988. 

Qualifications for the candidate include (a) 
an earned doctorate in computer engineering, 
electrical engineering or related discipline, (b) 
strong leadership capabilities in both spon¬ 
sored research and graduate teaching ac¬ 
tivities, (c) capability to interact productively 
with the industrial community and govern¬ 
mental agencies in the area, (d) strong 
evidence of scholarly activity, (e) U.S. Citizen¬ 
ship, and (f) a national and international 
reputation in the fields of software and hard¬ 
ware computer engineering. 

The Chair is expected to work closely with 
the faculty of the Department and the Col¬ 
leges of Engineering and Science, and to in¬ 
teract with University research units such as 
the Center for Robotics, the Center for Ap¬ 
plied Optics, the Cognitive Systems Labo¬ 
ratory, and the Artificial Intelligence Learning 
Center. 

The College of Engineering, the University, 
local industry and the Federal agencies of the 
area strongly support the Chair and provide 
an excellent environment and support facili¬ 
ties for research at the highest level. UAH has 
access to excellent computer facilities, in¬ 
cluding a State Supercomputer (CRAY 
X-MP/24) which is located adjacent to the 
UAH campus. Huntsville is a high-technology 
city with congenial living and unique cultural 
environment. 

Nominations and vitae with the names, ad¬ 
dresses and telephone numbers of references, 
should be sent to: Dr. Lynn D. Russell, Dean, 
College of Engineering, University of 
Alabama in Huntsville, Huntsville, Alabama 
35899. 

The position will remain open until an ac¬ 
ceptable candidate is found; however, the 
Search Committee will begin reviewing ap¬ 
plications not later than May 15, 1988. 

The University of Alabama in Huntsville is 
an Equal Opportunity/Affirmative Action 
Employer. 


TULANE UNIVERSITY 

Tulane is a major private university, selec¬ 
tive in enrollment and comprehensive in 
scope, with about 10,000 undergraduate and 
graduate students. The campus is located in a 
residential area of uptown New Orleans, one 
of America’s most distinctive cities. Faculty 
benefits include dependent tuition, mortgage 


assistance, relocation expenses, 12% TIAA 
and typical insurance benefits. 

Departmental computer systems include a 
VAX 11/780 running under VMS, aPyramid 
90x running under Unix, a Sun network, and 
several microcomputer clusters. The Pyramid 
is dedicated to departmental research; other 
systems are divided between research and 
teaching. In addition to departmental 
resources, the University maintains an IBM 
3081/KX. 

The department invites applications for 
faculty positions at all levels for the 1988-89 
academic year. Candidates should have a 
Ph.D. in Computer Science or a related area. 
Research excellence or demonstrated re¬ 
search potential and a commitment to quality 
teaching are required. Applicants for instruc- 
torships must possess a masters in Computer 
Science or be ABD. 

Applications should be directed to 
Dr. Johnette Hassell, Head 
Department of Computer Science 
School of Engineering 
301 Stanley Thomas Hall 
New Orleans, LA 70118 

Applications must be received by July 1, 
1988 for spring appointment. Tulane Univer¬ 
sity is an Affirmative Action Equal Opportuni¬ 
ty Employer. 


ELECTRICAL ENGINEER 

ELECTRICAL ENGINEER (SR.), requires 
M S. in Electrical Engineering or Computer 
Science, with three years experience in the job 
offered or three years in Electrical or Systems 
engineering. 40 hrs./wk, $35,000/yr. salary. 
EOE. Duties: using digital circuit and software 
design techniques, designs microprocessor/ 
microcomputer-based systems with devices 
such as Motorola 68000 and TI-34010; 
designs computer peripheral equipment in¬ 
cluding laser printer and print engine inter¬ 
faces, direct memory access (DMA) con¬ 
trollers, Raster image processors, computer 
bus interfaces for VME and IBM AT, and pro¬ 
grammable array logic (PAL) integrated cir¬ 
cuits; conducts timing analysis and verifica¬ 
tion, power consumption calculations, output 
loading consideration, logic simulation, and 
protype testing and debugging; diagnoses and 
corrects hardware and software product 
design flaws; supervises junior electrical 
engineers; assumes lead on engineering pro¬ 
jects; provides technical support to manage¬ 
ment. Also requires thorough knowledge and 
experience with: high speed laser printer con¬ 
troller design; advanced digital logic and soft¬ 
ware design such as DRAM and DMA control 
and state machine design; microprocessor/ 
microcomputer-based systems design using 
devices, such as Motorola 68000 and TI 
34010; CAD/CAE work stations for mixed 
analog/digital systems design; PAL design; 
computer bus interface design for computers 
such as VME and IBM AT; and high level pro¬ 
gramming languages. Apply or send resume 
to Ms. O. Pillion, Alabama State Employment 
Service, 4613 Springhill Avenue, P.O. Box 
81309, Mobile, Alabama 36689. JO 
*452410. 


NAVAL POSTGRADUATE SCHOOL 
Computer Science Chairperson 

The Naval Postgraduate School invites ap¬ 
plications and nominations for the position of 
Chairperson of the Computer Science 
Department. We are seeking an individual 
who can provide leadership in both teaching 
and research to a strong and growing pro¬ 
gram. This person must have a Ph.D. in 
Computer Science or a closely related area 
and a distinguished record of research and 
publication as well as demonstrated adminis¬ 
trative capability. 

The Department offers M.S. and Ph.D. 
degrees in Computer Science. Currently, 110 
students are enrolled in the M.S. program and 
five in the Ph.D. program. No undergraduate 
degrees are offered. Students are military of¬ 
ficers or civilian employees of the Department 
of Defense and are fully supported by their 
sponsoring organization during their graduate 

The faculty currently consists of thirteen full¬ 
time civilian faculty, five military faculty, and 
several adjunct faculty. Additional positions 
are open in all areas. Departmental facilities 
(supported by eight full-time computer profes¬ 
sionals) consist of six instructional and re¬ 
search laboratories including the Database 
Systems Laboratory, the Graphics and Video 
Laboratory, the Software Engineering Labo¬ 
ratory, the Microcomputer Systems Labora¬ 
tory, the Artificial Intelligence Laboratory, and 
the Computer Science Academic Laboratory. 
In these laboratories are state-of-the-art com¬ 
puting equipment including a VAX 780, a 
VAX 785, LISP machines, high-performance 
graphics workstations, bit-mapped graphics 
workstations, and multi-microprocessor 
systems. 

Located on Monterey Bay, the areas of 
Monterey, Pebble Beach, and Carmel pro¬ 
vide a pleasant Northern California coastal 
climate and easy access to Silicon Valley com¬ 
panies and universities. 

Please send a detailed resume and letters of 
reference to: 

Chair Search Committee 

Computer Science Department (Code 52) 
Naval Postgraduate School 
Monterey, CA 93943 
Tel. No. (408) 646-2449 

AN EQUAL OPPORTUNITY/ AFFIRMA¬ 
TIVE ACTION EMPLOYER. 


UNIVERSITY OF CINCINNATI 
Assistant/Associate Department Head 
Department of Electrical and 
Computer Engineering 

Applications are invited for a newly created 
position of Assistant/Associate Department 
Head for the Computer Engineering pro¬ 
gram. The candidate is expected to have 
strong academic experience and an estab¬ 
lished research program, including funded 
research. We are particularly interested in a 
person with experience in one of the following 
research areas: artificial intelligence and expert 
systems, parallel processing, VLSI system 
design and testing, digital systems, computer 
aided design, computer architecture, software 
engineering, languages, compilers and data 
structures, operating systems, computer 
graphics and fault tolerant computing. The 
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candidate should have a strong commitment 
to teaching at the undergraduate and gradu¬ 
ate levels and be able to attract external fund¬ 
ing as a part of a vigorous sponsored research 
program. An earned doctorate is required. 
The department offers the B.S., M.S. and 
Ph.D. degress in both electrical and computer 
engineering. The B.S. degrees are accredited. 
The department has 27 full time faculty, 105 
full time graduate students, 425 under¬ 
graduate students and externally funded re¬ 
search of $1.5M annually. Salary and benefits 
are extremely attractive. The Department has 
several SUN systems networked together, a 
VAX 750, a VAX 785, an HP 9000/550, as 
well as access to the College HP 840, the 
University VAX network and University Am¬ 
dahl 470. Convenient access also exists over 
high speed lines to the State of Ohio Cray 
supercomputer. Applicants should send their 
resume to Dr. Vik J. Kapoor, Head, Electrical 
and Computer Engineering, Mail Location 
*30, University of Cincinnati, Cincinnati, 
Ohio 45221-0030. Applications will be con¬ 
sidered until the position is filled. The Univer¬ 
sity of Cincinnati is an Affirmative Action/ 
Equal Opportunity employer. 


THE FLINDERS UNIVERSITY 
OF SOUTH AUSTRALIA 
Discipline of Computer Science 
Lecturer /Senior Lecturer in 
Computer Science 

Applications are invited for the position of 
Lecturer/Senior Lecturer in the Discipline of 
Computer Science. Applicants should hold a 
postgraduate degree, preferably a Ph.D. in 
Computer Science. Duties will include under¬ 
graduate and honours level teaching, and the 
supervision of research students. Appoint¬ 
ment at the Senior Lecturer level would re¬ 
quire a significant record of achievement in 
research and teaching. The position is avail¬ 
able immediately. 

The Discipline offers a Computer Science 
major, honours programme and postgradu¬ 
ate opportunities. Machines used for teaching 
include two Sun 4/260’s, a Sun 3/280 and 
various work stations and personal com¬ 
puters. The Discipline presently comprises 15 
members of staff, including seven positions at 
lecturer or above. Further information may be 
obtained from Dr. M.J. Brooks, Discipline of 
Computer Science, or by telephone on (08) 
275 2662, or by electronic mail on mjb@cs. 
flinders.oz.au. 

Salary Scale: Lecturer: $A28,694- 
$A37,435 (an appointment will not be made 
above the sixth level of the scale viz. 
$A34,937). Senior Lecturer: $A38,216- 
$A44,403. 

Flinders University is situated in the 
Southern suburbs of Adelaide in the foothills 
of the Mount Lofty Ranges and overlooks the 
City and St. Vincent’s Gulf. The University 
has earned a reputation for its excellent record 

Applications, including a full curriculum 
vitae, details of academic record and publica¬ 
tions, research interests, and the names and 
addresses of three referees should be lodged, 
in duplicate, with The Registrar, The Flinders 
University of South Australia, Bedford Park, 
S.A., 5042, by 17 June, 1988. 


Software 

Engineers 


Northrop Corporation's Defense Systems Division develops em¬ 
bedded, real-time software for airborne radar and electro-optical/ 
infrared countermeasures applications. In addition, we conduct in¬ 
dependent research and development in software development 
techniques and artificial intelligence control concepts. 
Emphasis is on programming In the "C” and Ada languages fol¬ 
lowing a structured design methodology and supported by 
graphics-based Interactive development tools. Our state-of-the-art 
software development environment is implemented on a VAX 
cluster configuration, running under VMS, connected to SUN 
workstations on an Ethernet LAN, running under Un ix. Each soft¬ 
ware engineer has a terminal or workstation providing access to 
all computing resources on the network. 

Our expanding software development requirements have created 
the following employment opportunities: 

Software Development Project Managers 

To lead design teams in the development of real-time operational 
flight programs and their subsequent integration with the 
countermeasures hardware. Project responsibilities include the 
planning and management of schedules, budgets and staffing 
requirements. These positions require a Bachelor’s degree in a 
technical field with some computer science content and a minimum 
of eight years relevant experience, including experience in the 
development of large-scale “C" or Ada programs in a disciplined 
environment containing configuration management and quality 
assurance components. Also desirable are an advanced degree, for¬ 
mal management training, and avionics industry experience. 

Software Architects 

To initiate design projects and perform requirements analyses, 
algorithm development, and high-level design. These positions re¬ 
quire an advanced technical degree and format computer science 
training together with at least five years experience in the develop¬ 
ment of large-scale real-time embedded software. Experience In 
structured design methodology in a military standards environment 
and prior exposure to knowledge-based expert-systems and object- 
oriented programming techniques are also desirable. 

Software Systems Development Engineers 


To participate as iii 


ridual c 


>r group leaders in the 


detailed design, coding, testing and Integration of embedded real¬ 
time software. These positions require a Bachelor's degree In com¬ 
puter science, or equivalent, and at least three years experience 
In developing software in the * ‘C” or Ada languages using a struc¬ 
tured design methodology. Knowledge of computer hardware ar¬ 
chitectures, performance simulation and modeling, and Kalman 
filtering algorithms is also desirable. 

Software Tools Development Specialists 

To evaluate and/or develop tools to enhance software development 
productivity. These positions require a Bachelor's degree In com¬ 
puter science, or equivalent, and at least three years experience 
in software tools development. Experience with the Unix operating 
system, bit-mapped graphics displays, graphics standards, and win¬ 
dowing environments would be beneficial. 

Northrop will provide an equitable compensation and benefit 
package commensurate with level of experience. Ybur resume with 
compensation history will indicate your interest. Forward to: 
Supervisor-Staffing, Dept. CAS, Northrop Corporation, Defense 
Systems Division, 600 Hicks Road, Rolling Meadows, IL 60008. 
We are an equal opportunity employer M/F/V/H. U.S. Citizenship re¬ 
quired for certain positions. 
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Seventh Phoenix Conference features three speakers, SDI debate 


Mark B. Fishman, Eckerd College 

In virtually every aspect, from the 
technical variety of the program to the 
wit of the invited speakers to the 
enthusiasm of participants from a 
dozen countries, the seventh Phoenix 
Conference on Computers and Commu¬ 
nication was a success. 

PCCC 88, sponsored by the IEEE in 
conjunction with the Computer Society, 
the IEEE Communications Society, the 
Phoenix IEEE chapter, and Arizona 
State University, was held in mid-March 
in Scottsdale, Ariz. Carl Ryan of 
Motorola was general chair. 

Interwoven with the invited addresses 
and the technical and plenary panel ses¬ 
sions was a full roster of more than 100 
technical papers on computer technol¬ 
ogy, communication technology, soft¬ 
ware technology, networking technology, 
and artificial intelligence technology. 
Ten day-long tutorials were presented 
March 16. 

The conference was highlighted by 
three informative addresses and a 
stimulating debate on the controversial 
Strategic Defense Initiative. 

Conference speakers. John McCarthy 
of Stanford University delivered a rous¬ 
ing keynote address March 17 entitled 
“Current and Future Applications of 
Artificial Intelligence.” In it, he 
expressed his hope for development of a 
common business communications lan¬ 
guage (CBCL). 

McCarthy described what he called 
the “world of the future,” a 1965 para¬ 
digm of artificial intelligence he had 
actually encountered in an article from 
that era. In this glorious world, a pur¬ 
chaser sitting at a terminal is informed 
by an “intelligent” program that her 
company needs 5,000 pencils. She, in 
turn, calls another human, seated at a 
terminal in another company, asking 
that an order be entered into his com¬ 
puter for 5,000 pencils. 

The humans and their analog com¬ 
munication are the conduit through 
which two intelligent machines conduct 
the business of their respective compa¬ 
nies, and why, McCarthy asks, do we 
need to develop intelligent programs 
that cannot communicate except 
through the shaky, low-baud interac¬ 


tions of consenting humans? 

The speaker said that developing a 
CBCL could provide the answer to the 
question. 

In the day’s luncheon address, 
Emmett Paige, Jr., a lieutenant general 
and head of the US Army Information 
Systems Command, made a good- 
humored appeal to “give shoes,” at 
last, “to the cobbler’s children” by 
automating the software development 
process. His talk was entitled “Experi¬ 
ences and Challenges of Global Com¬ 
munications.” 

According to Paige, the USAISC, 
organized in 1984 as a consolidation of 
what were formerly the communica¬ 
tions and computer systems commands 
and now comprising some 40,000 staff 
members, “spends about 98 percent of 
its time on automation systems.” 

“Communications,” he noted, “is in 
good shape compared to automation.” 
Generally, software design, said Paige, 
“is the major issue and the major 
problem.” 

He recalled “big MIS systems written 
20 years ago by bad programmers who 
didn’t document their code properly, 
and most of them are gone now. Let’s 
face it—software is just bad news.” 

Despite his concerns, Paige is 
enthusiastic about the advent of net¬ 
working (“an overarching umbrella that 
will pull everything else together”), AI 
and expert systems, and, most particu¬ 
larly, Ada. “For the US Army, Ada is 
it. We look at Ada as our salvation,” 
he said. 

E. Baird Smith of the IBM Corporate 
Technical Education Center presented 
the luncheon address March 18 on 
“Softworld: The World of ‘Virtual 
Reality’ Where All Experience is 
Manufactured.” Smith discussed what 
is coming in the digitization of reality. 

Digital technology—technology in 
general—he observed, has changed for¬ 
ever the way in which we perceive our 
world. Smith asked the audience if there 
was anyone present “of the VCR gener¬ 
ation” who, sitting through a board 
meeting, has not wished he or she could 
press the fast-forward button? And, 
who has not wished to “mouse” whole 
elements of his/her world in and out of 
the scene? 

Smith traced the development of 


science from the physical to the virtual, 
referring to a series of colorful histori¬ 
cal slides: “Here we see the very partic¬ 
ulate Newtonians of the past, with a 
very nice way of explaining those basic 
questions, such as, ‘When I let go, why 
does it drop?”’ 

But now, “we have new questions for 
which physics has no answers what¬ 
soever, like, ‘When I log in, why does it 
crash?”’ 

Smith went on to explore the onto¬ 
genesis of our “info-history” and asked 
“What was it like when there was no 
information?” He answered the ques¬ 
tion by projecting a darkened slide onto 
the screen. 

“Perhaps, one day, there was one bit. 
It was infinitely small and infinitely 
dense. Then, one day, that bit... 
exploded. That’s it! The ‘Bit Bang The¬ 
ory’,” Smith called it. 


SDI panel. The plenary panel session, 
“The Great SDI Debate,” concluded 
the conference March 18. Thaddeus 
Regulinski of Loral was the moderator. 

The Pentagon’s John Donegan, pro¬ 
gram manager of Phase I of the Strate¬ 
gic Defense Initiative, led off the 
discussion by citing President Reagan’s 
justification for SDL 

“Most people in this country do not 
know that there are no defenses against 
ballistic missiles active in this country 
today, and that the only country that 
does have such defenses is the Soviet 
Union,” Donegan said. 

“Most people believe that having 
defenses would be preferable to the 
present operation of mutually assured 
destruction as a mechanism for deterrence, 
and that’s how the SDI is proceeding.” 
In recounting “things that have been 
accomplished in the past few years,” he 
cited design and testing, networking, 
communications technology, and algo¬ 
rithm work. 

“In summary, we’ve defined a Phase 
I system, the demonstration and valida¬ 
tion program is progressing, we’ve com¬ 
pleted a study recently on what we need 
in the mid-course sensor area, how 
much processing we need, how many 
objects we’ll have to track, our concepts 
are being worked in a large variety of 
technology efforts, and I think that 
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Huang, Williams deliver keynote talks at 1988 
VLSI Workshop 

Paul B. Cohen, Massachusetts Microelectronics Center 


we’ll be able to show that Phase I of 
SDI will have military and operational 
utility,” Donegan said. 

The next panelist, Alan Kline, a 
faculty member of the Department of 
Computer Science at the University of 
Texas at Austin, observed that the ques¬ 
tion addressed, “Are computers and 
communications the key to SDI suc¬ 
cess?” was perhaps the wrong question, 
and that it might be more appropriate 
to ask, “Are they the key to SDI 
failure?” 

“I believe that the question is not 
whether SDI can be written,” Kline 
said. “The question is whether it can be 
trusted.” He proceeded to conduct a 
demonstration, turning on a red flash¬ 
light and, 50 seconds later, turning it 
off. He reviewed previous instances of 
software failure in defense systems, 
including one false alert caused by soft¬ 
ware that confused the rising of the 
moon with an incoming missile attack 
and another, in 1979, caused by mount¬ 
ing the wrong tape. 

“If the Soviet Union goes to a 
50-second booster phase on their mis¬ 
siles, then, during the time that this 
flashlight was on, the system would 
have to recognize the signals from those 
boosters, determine the trajectories of 
those rockets, coordinate all of the vari¬ 
ous weapons, assigning various weapons 
to various targets, aim, and fire all 
those weapons. That worries me,” he 
said. 

“I believe that we have learned some¬ 
thing about software over the last 30 
years in building things and, yes, it is 
possible to build software,” said Kline. 
“But, no, it is not possible to build 
software of such complexity that can be 
trusted the very first time it is used. ” 

Tony Pizzarello of Honeywell Bull, 
introduced as representing the perspec¬ 
tive of industry, pointed out that we did 
have existing multimillion-line programs 
and that, generally, only a small portion 
of that extended code would be running 
most of the time. 

This prompted a member of the 
audience to ask whether Pizzarello 
knew of any system in which it was the 
unimportant part that would be running 
most of the time, but the absolutely 
critical part (what to do in the event of 
an exception) that would remain rela¬ 
tively untested. 

Mark Reader, a political scientist 
from Arizona State University, spoke 
from a social science perspective. The 
thrust of his argument was simply that 
man is fallible, and that it ill-behooves 
him to develop technologies that stand 
to punish him so drastically, in this case 
perhaps by extinction, for the errors he 
is bound to make. 


Alan Huang of AT&T Bell Laborato¬ 
ries and Tom Williams of IBM were the 
keynote speakers when the Computer 
Society VLSI Technical Committee con¬ 
ducted its annual VLSI Workshop 
February 28 to March 2 in Clearwater 
Beach, Fla. 

C.K. Wong of IBM and Don Bouldin 
of the University of Tennessee served as 
program chair and workshop chair, 
respectively. 

In his talk, Huang pointed out that, 
in a digital system, most of the speed is 
lost in data communication, both on 
and between chips. Optical computing 
facilitates very high speed and can 
achieve a high degree of parallelism. 

Huang proposed a technique called 
“logic origami,” where a computation 
can be folded to achieve an arbitrary 
hardware/time trade-off, and another 
technique called “symbolic substitu¬ 
tion” to force a computation into a 
regular format amenable to optical 
interconnection. 

Williams began his address on 
“Testability and VLSI” with a tutorial 
on test techniques, including pseudo¬ 
clock, bed-of-nails, signature analysis, 
and level-sensitive scan design. Looking 
towards the future, he observed that 
99-percent fault coverage is not ade¬ 
quate for large chips. In response to 
this, he said design-for-test techniques 
will be increasingly common, and syn¬ 
thesis tools that can generate testable 
logic will be needed. 

Takayuki Yanagawa of Nippon Elec¬ 
tric was chair of the session entitled 
“Special Report from Japan,” with Sei- 
ken Yano and Masahiro Yamamoto of 
Nippon Electric, Shinpei Hijiya of 
Fujitsu, and Tokinori Kozawa of 
Hitachi serving as panelists. 

Yano’s talk was entitled “VLSI 
Chips for Mainframe Computers.” In 
it, Yano said that, with the current 
trend in emitter-coupled logic VLSI, he 
envisions the availability of 10,000-gate 
chips by 1990, with power dissipation 
approaching 30 watts. To keep the 
power dissipation and design time to 
reasonable values, low-energy current¬ 
mode logic combined with master-slice 
techniques are being investigated. In 
addition, many of the test issues 
addressed in other talks are now becom¬ 
ing issues for ECL chips as complexity 
increases. 

Hijiya’s talk was entitled “Experi¬ 
ence with Wafer Scale Integration in 
Japan,” and in it he discussed both the 
overall effort in Japan (which he said is 


admittedly small) and Fujitsu’s work in 
WSI. The problems facing WSI include 
yield, packaging, stress, and I/O. 
Restructuring techniques are being 
investigated to solve some of these 
problems. Fujitsu is working on a fast- 
Fourier-transform wafer, using 170,000 
gates and 725 I/O ports. This design 
uses a single repeatable block with 
programmable wiring between blocks. 

Kozawa’s talk, “CAD System for 
Machine Design,” focused on the 
design of a series of mainframe 
machines and the tools used in the 
design. One of the methods is to trans¬ 
late electrical requirements (for exam¬ 
ple, propagation delay) into wire-length 
limitations that can be rapidly fixed by 
the CAD tools. 

Yamamoto reported on “Fifth 
Generation Computers in Japan.” He 
said that projects are under way at a 
number of universities, national labora¬ 
tories (ICOT and ETL), and compa¬ 
nies. Yamamoto discussed areas of 
specific interest as well as products, 
where applicable. Some of the interest 
areas are natural-language processing, 
machine translation, and knowledge- 
based and expert systems. 

Twenty-nine technical papers were 
presented during the workshop. It was 
formatted as an off-the-record technical 
exchange between experts in the art, 
and attendees were encouraged to 
remain for the entire workshop to 
encourage communication between 
experts with different specialties. 
Because of the workshop’s format, no 
proceedings will be published. 

Further information on the workshop 
may be obtained by contacting VLSI- 
TC bulletin editor Sunil Das at the 
Department of Electrical Engineering, 
University of Ottawa, Ottawa, Ontario, 
Canada KIN 6N5. 

Planning for the 1989 workshop is 
under way. W. Ron Young of Harris 
Semiconductor and P.A. Subrah¬ 
manyan of AT&T will serve as program 
co-chairs, with Bouldin once again serv¬ 
ing as workshop chair. 


Correction 

The title of an article that ran on p. 
143 of the March 1988 issue of Com¬ 
puter should have read “Innovator of 
Petri nets keynotes international 
workshop.” 
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NCGA 88 emphasizes integration of systems 

Tom Culviner, Assistant Editor, IEEE Computer Graphics and Applications 


NCGA 88, the National Computer 
Graphics Association’s ninth annual 
conference, emphasized system integra¬ 
tion in two special events—Integrate 88, 
a tour of applications linking indepen¬ 
dent systems, and the Annual Corporate 
Meeting, an expert analysis of industry 
trends. The conference, which drew 
36,104 people to the Anaheim, Califor¬ 
nia, Convention Center March 20 to 
March 24, also featured an exposition 
of nearly 250 new products and three 
software shootouts. 

Integrate 88. The “show within a 
show” at NCGA was Integrate 88, 
where 33 independent systems, com¬ 
posed of products from 40 different 
companies, were distributed about the 
Pacific Room of the Anaheim Conven¬ 
tion Center. Half-hour demonstration 
tours—each featuring one of eight 
different applications—were conducted 
from March 21 to March 23. 

The tours demonstrated how produc¬ 
tivity can be increased by eliminating 
the “islands of automation” that result 
when departments automate indepen¬ 
dently and cannot exchange informa¬ 
tion electronically. 

In all the applications demonstrated, 
information was exchanged among the 
engineering, finance, graphic arts, and 
publishing departments of hypothetical 
companies. The link between the com¬ 
puters in the departments was the appli¬ 
cation profile of the Computer Graphics 
Metafile specified in TOP Version 3.0. 
The CGM files were exchanged over a 
thin-wire Ethernet system. All the hard¬ 
ware and software used in the demon¬ 
stration are available today. 

In one of the eight tours, the genera¬ 
tion of a report began in the engineering 
department of the “Black Gold Oil 
Company. ” An operator in the engineer¬ 
ing department used a Sun workstation 
and Sierra Geophysics Mimic contour¬ 
ing software to determine the best per¬ 
spective of a view of a drilling area. 
Once the best image was selected, it was 
sent by the network to the publishing 
department. 

Meanwhile, the finance department, 
using Lotus Graphwriter II and Lotus 
Freelance Plus on an IBM PC AT, had 
put together an analysis chart, which it 
sent to the graphic arts department for 
visual enhancement and the creation of 
a slide to supplement the report. Once 
the graph was enhanced, it too was sent 
to the publishing department. 

In the publishing department, the 
images from the two departments were 


merged with text on Wang office auto¬ 
mation products, and a two-page 
“drilling report” was generated. Aside 
from the writing of the text, the whole 
process took about 20 minutes. 

Industry trends. “We build systems; 
we don’t build workstations,” Roland 
D. Pampel said at the Annual NCGA 
Corporate Meeting held March 22. The 
president and chief operating officer of 
Apollo Computer was explaining 
Apollo’s approach to designing sys¬ 
tems, as well as what he sees as the 
general trend in design in the graphics 
workstations industry. 

Pampel expects continuation of the 
pattern that brings a tenfold improve¬ 
ment in workstation performance every 
seven years. This trend, coupled with 
customers’ desire to network worksta¬ 
tions, will necessitate improving local 
area network transmission speeds to 100 
megabits per second, a development 
that Pampel expects very soon. 

Pampel sees future users expecting to 
do most of their work at or below the 
desk, rather than in the mainframe. 
Mainframes will still have their place, 
however, in such tasks as the handling 
of large shared databases. 

Users won’t want to worry about 
different operating systems and will 
want to view simultaneously on one 
screen files running under different sys¬ 
tems. The likely means for accomplish¬ 
ing this will be X Windows, Pampel 
said. 

Pampel seemed discouraged with the 
status of the Programmer’s Hierarchi¬ 
cal Interactive Graphics Systems 
(PHIGS), now an American National 
Standard and an International Stan¬ 
dards Organization draft standard. “I 
wish the real PHIGS would stand up 
and stand still,” Pampel said. 

Looking at the 1990s, Pampel predicted 
that heterogeneous networking of 
different systems and machines from 
different families would be common. 
For example, the graphics of a simula¬ 
tion could run on a workstation while a 
Cray computer did the simulation. At 
all times the user at the workstation 
would retain the ability to change the 
simulation interactively. 

After Pampel’s address, questions 
about industry trends were directed to 
Kenneth D. Anderson, publisher of The 
Anderson Report-, Charles Foundyller, 
president of Daratech; and Carl 
Machover, president of Machover 
Associates. 

The first question concerned the 


future of at-the-desk computing— 
would it depend on the trend of 
decreasing prices for workstations or 
that of increasing performance in 386 
PCs? 

Machover responded by noting his 
dislike for the distinction between PCs 
and workstations. A more useful 
approach, he said, is to place machines 
in a price-based hierarchy of low-end 
machines costing $10,000 or less, 
midrange machines costing $20,000 to 
$40,000, and high-end machines costing 
more than $50,000. Performance in all 
areas will continue to improve, but, as a 
rule, the low end will perform at about 
one-tenth to one-half the midrange rate, 
while the high end will perform at two 
to five times the midrange rate. 

Anderson said that a major distinc¬ 
tion between a PC and a workstation is 
that workstations are more easily net¬ 
worked. Foundyller noted that continued 
blurring of distinctions is a likely trend, 
especially because Apollo and Sun 
workstations will soon be sold in store¬ 
front locations. 

Foundyller, responding to a question 
about the future of Unix, said Sun and 
AT&T are trying to make Unix a stan¬ 
dard, but Hewlett-Packard and other 
companies are resisting. They want any 
such standard to be established through 
the committee process. 

According to Foundyller, OS/2 may 
gain wider acceptance than now seems 
likely, eventually pushing Unix to the 
wayside. He said OS/2 is more effective 
than most people realize, its capabilities 
are increasing, and software that runs 
under it is less expensive than Unix 
software. 

Anderson agreed that AT&T and Sun 
are pushing Unix hard, and that Unix is 
not yet a standard. He foresees a possi¬ 
ble two-standard outcome; Unix would 
be one standard, and there would be 
another one agreed upon by the vendors 
now resisting Unix. Most important, 
Anderson said, is that users should be 
protected from any unproductive conse¬ 
quences of such industry squabbles. 

Machover thought that we would see 
manufacturers striving to produce 
machines that could run all the different 
operating systems. He also felt that the 
market needs what he called “ASWS”— 
application-specific workstations— 
designed for very specific uses. 

Shootouts. There were three software 
shootouts at NCGA 88. In the shootout 
for MicroCADD software for under 
$500, DesignCAD 3.0 from American 
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Small Business Computers was the win¬ 
ner. The other entrants, in descending 
order by the number of votes that they 
received, were Foresight Resources’ 
Drafix 1 Plus, Generic Software’s 
Generic CADD 3.0, Evolution Comput¬ 
ing’s EasyCAD 2.0, and MATC-CAD’s 
Matix. 

Zenographics’ Pixie won the business 
graphics package for the IBM PC 
shootout, receiving one more vote than 
Ashton-Tate’s Draw Applause. Other 
packages entered, again in descending 
order according to votes received, were 
Software Publishing’s Harvard Graphics, 
Hewlett-Packard’s Graphics Gallery, 
and Micrografx’s Windows Graph. 

The desktop publishing package 
shootout was an exciting and conten¬ 
tious session, with company experts 
demonstrating their products and some¬ 
times verbally attacking each other. 

The ballot was complex, breaking 
down votes into such categories as 
“best typographic features” and “most 
flexible design tool.” Xerox’s Ventura 
Publisher, Digital Research’s Gem Pub¬ 
lish, and Aldus’ PC PageMaker were 
the contestants in the IBM PC shootout; 
PageMaker was the overall winner. On 
Macintosh hardware, PageMaker com¬ 
peted with Quark XPress and Ready,Set, 
Go! from Letraset, emerging again as the 
overall winner. 


Awards. NCGA presented five awards 
for outstanding achievement at the Video- 
Gala dinner, held at the Anaheim Marriott 
on March 22. 

Ken Olsen, president and founder of 
Digital Equipment Corporation, 
received NCGA’s Industrial Productiv¬ 
ity Medal. NCGA commended his work 
to advance computer graphics and pro¬ 
mote industry-wide systems integration. 

Thomas H. Bruggere was named 
NCGA Executive of the Year. Bruggere 
is founder and CEO of Mentor 
Graphics. John Walker, founder and 
chairman of the board of Autodesk, 
received the NCGA Award for Techni¬ 
cal Excellence. The winner of the 
NCGA Award for the Advancement of 
Computer Graphics was Raye J. Mon¬ 
tague of the US Naval Sea Systems 
Command. 

NCGA presented a new award this 
year, the NCGA Academic Award. The 
recipient was Michael J. Wozny, direc¬ 
tor of design, manufacturing, and 
computer-integrated engineering at the 
National Science Foundation. Wozny is 
also the founding director of the Center 
for Interactive Computer Graphics at 
Rensselaer Polytechnic Institute and a 
former editor-in-chief of IEEE Com¬ 
puter Graphics and Applications. 


Leaders have enormous impact. Others tend to watch, analyze 
and imitate a leader. American industry needs world class 
leaders. Intel and Arizona State University have joined forces 
to create a dynamic new graduate study program with the 
goal of developing young leaders able to meet the manufac¬ 
turing and technology challenges of the global marketplace of 
the future. 

The Department of Computer Science at Arizona State 
University invites applications for its 1988 Intel Industrial Fellows 
Program For Master’s Degree Studies In Engineering and Com¬ 
puter Science. Sponsored by the Intel Corporation, with several 
locations in the Phoenix metropolitan area, this program offers 
an excellent opportunity for two outstanding engineers to earn 
a master's degree in computer science or computer engineer¬ 
ing from one of the nation’s best engineering colleges, and, at 
the same time, gain valuable work experience at one of the 
world’s leading microelectronics manufacturing corporations. 

Intel Industrial 
fellows Program 

An Innovative Leadership Program Aimed At 
Improving America’s Competitiveness 

Terms of Awards: This program will combine a two year 
master of science in computer science degree program, cov¬ 
ering the 1988-89 and 1989-90 academic school years, with 
part-time work (20 hours per week) at Intel. Fellows will be 
employed by Arizona State University as graduate research 
assistants. A salary of $11,000 plus a full tuition waiver, health 
insurance, and a book allowance will be provided for each 
academic school year, and Fellows are guaranteed a summer 
job (with a minimum salary of $6,000) for the summer of 1989. 

Selection criteria: The ideal applicant will have a bachelor’s 
degree from an ABET accredited institution in computer science, 
computer engineering, or electrical engineering. Relevant work 
experience is a plus, as are excellent grades. U.S. citizenship is 
required. Arizona State University vigorously pursues affirmative 
action in its employment, activity and programs. 

Application procedure: Obtain an application packet by 
writing to the address below. Applications are due June 17. 

For more information contact: 

The Intel Industrial Fellows Program 
College of Engineering and Applied Sciences 
Arizona State University 
Tempe, AZ 85287-5906 
(602) 965-2966 
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Alford, Wolff to keynote conference on distributed computing systems 


Mack Alford of Ascent Logic and 
Stephen Wolff of the National Science 
Foundation will be the keynoters when 
the eighth International Conference on 
Distributed Computing Systems 
(ICDCS) convenes June 13-17 in San 
Jose, Calif. 

Carl Davis of the University of Ala¬ 
bama, Huntsville, is general chair, and 
Walter Kohler of the University of Mas¬ 
sachusetts is the program chair. The 
conference is sponsored by the Com¬ 
puter Society and its Technical Com¬ 
mittee on Distributed Processing. 

In the keynote talks, Alford will 
focus on issues, trends, tools, and tech¬ 
niques for developing distributed com¬ 
puting systems, and Wolff will discuss 
future plans for NSFnet and other dis¬ 
tributed computing networks. 

According to Kohler, the conference 
objective is to encompass the technical 
issues associated with the specification, 
design, implementation, evaluation, 


and operation of distributed computing 
systems. 

To fulfill that objective, the ICDCS 
Program Committee established eight 
sub-areas: decentralized and parallel 
computer architectures; communication 
architectures and protocols; distributed 
operating systems; applications; dis¬ 
tributed database systems; languages, 
tools, and software engineering; relia¬ 
bility and fault tolerance; and modeling 
and performance evaluation. The com¬ 
mittee assigned a vice chair, a small 
subcommittee of members, and a large 
number of reviewers to each sub-area to 
develop the respective programs. 

Sixty-six papers, less than 30 percent 
of those submitted, were selected for 
presentation and were organized into 22 
sessions covering the full range of dis¬ 
tributed computing systems research. 

Each paper was assigned to one or 
two vice chairs for review by committee 
members and referees. At least three 
reviews were requested for each paper, 


and over 260 individuals contributed 
reviews. 

Kohler said he believes the large num¬ 
ber of papers submitted for review (222 
from 18 countries) is an indication of 
the expanding research activity in dis¬ 
tributed computing systems and the 
growing stature of the conference. 

He said he is particularly pleased with 
the large number of strong papers sub¬ 
mitted in the area of languages, tools, 
and software engineering. 

Sessions on concurrent programming 
languages, monitoring and debugging, 
and analysis of distributed software sys¬ 
tems are also included in the technical 
program. 

Leading researchers will conduct two 
full-day tutorials June 13 and two more 
June 17. 

Complete registration information, 
including details on discounts available 
to those registering before May 10, may 
be found in the ad that ran on pp. 124-125 
of the April issue of Computer. 


Order today! 


Four 

According 

to 

Protocol 


lb order your copies today, simply call 

1-800-526-7254 TOLL FREE 

In N J. call 1-201-348-4033. lb order by mail, 
simply write to: 

Springer-Verlag New York, Inc., 

Attn: E Balzac-Dept. S888 
175 Fifth Avenue, New York, NY 10010. 
Please include $2.50 for shipping (CA, NJ 
and NY residents please add sales tax). 

3/88 FB Printed in the U.SA. S888 


For a complete or introductory 
view, turn to... 

An Introduction to TCP/IP 

John Davidson 

Introduce yourself to the most widely 
used protocol suite in the networking 
world with this book. It describes the 
protocol suite according to the ISO 
seven-level (OSI) reference model and 
explains the role TCP/IP plays in fitting 
together various pieces of an overall 
networking scheme. 

1988/112 pp/30 illusypaperback/ 

ISBN 0-387-96651-X/$24.95 

The Complete Guide to 
TCP/IP Protocol Suite 
Don Huntington and 
George Cohn 

By presenting a clear description of 
each protocol, this comprehensive 
work will provide you with the neces¬ 
sary background to understand and im¬ 
plement TCP/IP 
Forthcoming in 1988 


Springer-Verlag 

New York Berlin Heidelberg Vienna 
London Paris Tokyo 


To perform a basic IC design, 
equip yourself with... 
Integrated Circuit Design 
Alan F. Murray and 
H. Martin Reekie 
Covering the technological details nec¬ 
essary to perform and understand a 
basic IC design, this self-contained in¬ 
troduction deals in detail with MOS 
technology while treating the strengths 
and weaknesses of important alter¬ 
native IC technologies. 

1987/147 pp. (approx.)/hardcover/ 

ISBN 0-387-91303-3/$28.00 

Explore the frontier of... 

Open Problems in 
Communication and 
Computation 

Edited by Thomas M. Cover and 
B. Gopinath 

Follow leading researchers into the 
frontier of the field as they present 
novel open problems ranging from sim¬ 
ple geometry (the simplex conjecture) 
to programming (algorithmic complex¬ 
ity) to information theory (capacity of 
networks). 

1987/236 pp./28 illusThardcover/ 

ISBN 0-387-96621-8/$25.00 
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CALENDAR 


May 1988 

Software Maintenance Assoc. Conference, 
May 15-18, Chicago. Contact Suzanne 
Grenoble, SMA, Box 391432, Mountain 
View, CA 94039; (408) 730-1132. 

CHI 88, Conference on Human Factors in 
Computing Systems (ACM), May 15-19, 
Washington, DC. Contact Gail A. Chu- 
mura, 5214 Monroe Dr., Springfield, VA 
22151; (703) 750-9401. 

Third International Conference on Super- 
computing, May 15-20, Boston. Contact 
Lana P. Kartashev, International Supercom¬ 
puting Institute, Suite B-309, 3000 34th St. 
South, St. Petersburg, FL 33711; (813) 
866-2694. 

Computers and Communications in the 
Healthcare Industry, May 16-17, Chicago. 
Contact Carol Every, Frost & Sullivan, 106 
Fulton St., New York, NY 10038; (212) 
233-1080. 

Second Symposium on Space C 3 (AFCEA), 
May 16-19, Annapolis, Md. Contact Randy 
Crawford/DQ, IIT Research Institute, 185 
Admiral Cochrane Dr., Annapolis, MD 
21401; (301)224-2295. 

NATO Advanced Research Workshop on 
Highly Redundant Sensing in Robotic Sys¬ 
tems, May 16-21, Tuscany, Italy. Contact 
Julius Tou, Center for Information Research, 
University of Florida, Gainesville, FL 32611; 
(904) 335-8018. 

CIPS Congress 88, May 18-20, Toronto, 
Canada. Contact Canadian Information 
Processing Society, 243 College St., 5th 
Floor, Toronto, Ontario, M5T 2Y1; phone 
(416) 593-4040. 

1988 International Industrial Engineering 
Conference, May 22-25, Orlando, Fla. Con¬ 
tact IIE Registrar, 25 Technology 
Park/Atlanta, Norcross, GA 30092; (404) 
449-0460. 


SID 88, May 23-27, Anaheim, Calif. Contact 
James N. Price, Naval Ocean Systems Cen¬ 
ter, Attn.: Code 713, San Diego, CA 92152; 
(619) 225-2665. 

18th International Symposium on 
Multiple-Valued Logic, May 24-26, 

Madrid, Spain. Contact Enric Trillas, Inves- 
tigaciones Cientificas, Serrano 117, 28006- 
Madrid, Spain; phone 34 (91) 621-6264. 

CG International 88 (CGS, BCS), May 
24-27, Geneva. Contact N. Magnenat- 
Thalmann, MIRALab HEC, 5255 Decelles, 
Montreal, Canada H3T 1V6. 

SIGMetrics 88, Conference on Measurement 
and Modeling of Computer Systems (ACM), 
May 24-27, Santa Fe, N.M. Contact Rebecca 
Koskela, SIGMetrics 88, Mail Stop B265, 
LANL, Los Alamos, NM 87545; (505) 
667-8887, or Connie U. Smith, L&S Com¬ 
puter Technology, 1114 Buckman Rd., Santa 
Fe, NM 87501; (505) 988-3811. 

International Conference on Systolic 
Arrays, May 25-27, San Diego. Con¬ 
tact Keith Bromley, Code 741-T, Naval 
Ocean Systems Center, 271 Catalina St., San 
Diego, CA 92152; (619) 225-7008. 

International Workshop on Artificial Intelli¬ 
gence for Industrial Applications (IEEE, 
SICE), May 25-27, Hitachi, Japan. Contact 
Takao Sasayama, Technology Planning 
Group, Hitachi America, 50 Prospect Ave., 
Tarrytown, NY 10591-4698; (914) 332-5800, 
or Kotaro Hirawawa, 10th Dept., Hitachi 
Research Laboratory, Hitachi, 4026 Kuji- 
cho Hitachi-shi, 319-12, Japan; (02) 
94-52-5111. 


15th IFAC Workshop on Real-Time Pro¬ 
gramming, May 25-27, Valencia, Spain. 
Contact WRTP 88, Grupo de Informatica 
Industrial—DSIC/DISCA, Universidad 
Politecnica de Valencia, PO Box 22012, 
E-46071 Valencia, Spain; phone (34) 
6-360-4041. 


41st SPSE Conference, May 22-27, Washing¬ 
ton, DC. Contact Society for Imaging 
Science and Technology, 7003 Kilworth 
Lane, Springfield, VA 22151. 


International CIM Conference, May 
^87 23-25, Troy, N.Y. Contact Lester 
Gerhardt, CIM Program, CII 8015A, RPI, 
Troy, NY 12180-3590; (518) 276-6400. 


Z2N Third International IEEE Conference 
^■7 on Ada Applications and Environ¬ 
ments, May 23-26, Manchester, N.H. Con¬ 
tact Derek S. Morris, Dept, of Electrical 
Engineering and Computer Science, Stevens 
Institute of Technology, Hoboken, NJ 
07730; (210) 420-5606. 


Eurocrypt 88, Workshop on the Theory and 
Application of Cryptologic Techniques 
(IACR), May 25-27, Davos, Switzerland. 
Contact Paul Schobi, Ltd., Althardstr. 70, 
CH-8105 Regensdorf, Switzerland. 

Hardware and Software Conference for 
Real-Time Process Control (IFIP, IFAC), 
May 30-June 1, Warsaw, Poland. Contact 
Krystyna Ornatkiewicz, Congress Bureau 
ORBIS, PO Box 146, PL-00-950, Warsaw, 
Poland; phone (48) 22-261-668. 


Z2N 15th International Symposium on 
^7 Computer Architecture (ACM), May 
30-June 3, Honolulu. Contact H.J. Siegel, 


Supercomputing Research Center, 4380 
Forbes Blvd., Lanham, MD 20706; (301) 
731-3700. 

Avignon 88, 8th International Workshop on 
Expert Systems and Applications (ECCAI), 
May 30-June 3, Avignon, France. Contact 
Jean-Claude Rault, EC2, 269-287, rue de la 
Garenne, 92000 Nanterre, France; phone 
(33) 1-47-807-000. 


June 1988 


SIGMod 88, Conference on Management of 
Data (ACM), June 1-3, Chicago. Contact 
Dina Bitton, Dept, of Electronic Engineering 
and Computer Science, University of Illi¬ 
nois, PO Box 4348, Chicago, IL 60680, (312) 
996-5492, or Peter Scheuermann, Dept, of 
Electrical Engineering and Computer 
Science, Northwestern University, Evanston, 
IL 60201;(312) 491-7141. 

First International Conference on 
^87 Industrial and Engineering Applica¬ 
tions of Artificial Intelligence and Expert 
Systems, June 2-3, Tullahoma, Tenn. Con¬ 
tact Richard Roberds, University of Tennes¬ 
see Space Institute, Tullahoma, TN 37388; 
(615) 455-0631. 


Conference on Computer Vision and 
^*7 Pattern Recognition, June 5-9, Ann 

Arbor, Mich. Contact Ramesh Jain, Dept, 
of Electrical Engineering and Computer 
Science, 3215 EECS Bldg., University of 
Michigan, Ann Arbor, MI 48109-2122; (313) 
763-0387. 


Enterprise Networking Event 88 Interna¬ 
tional (SME), June 5-9, Baltimore, Md. 
Contact Society of Manufacturing Engi¬ 
neers, 1 SME Dr., Dearborn, MI 48121. 

Third Israel Conference on Computer 
'v87 Systems and Software Engineering 
(Israel Section of the Computer Society and 
Information Processing Assoc, of Israel), 
June 6-7, Tel Aviv. Contact Jonah Z. Lavi, 
PO Box 50432, Tel Aviv 61500, Israel; phone 
(972)3-664825. 

Vision Interface 88, June 6-10, Edmonton, 
Canada. Contact Wayne A. Davis, Dept, of 
Computing Science, University of Alberta, 
Edmonton, Alberta T6G 2H1 Canada; 
phone (403) 432-3976. 

Second International Conference on Vector 
and Parallel Computing (SIAM), June 6-10, 

Tromso, Norway. Contact Berit Hilt, Bergen 
Scientific Center, Allegaten 36, 5000 Bergen, 
Norway. 
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ISCAS 88, IEEE International Symposium 
on Circuits and Systems, June 7-9, Espoo, 
Finland. Contact Pekka Heinonen, Tampere 
University of Technology, Computer Sys¬ 
tems Laboratory, PO Box 527, SF-33101 
Tampere, Finland; or Olli Simula, Helsinki 
University of Technology, Dept, of Techni¬ 
cal Physics, SF-02150 Espoo 15, Finland. 

ECCE 88, European Conference on Com¬ 
munication and Enterprise (AFCET), June 
7-10, Paris. Contact Conference Secretariat, 
ECCE 88, 156, boulevard Pereire, 75017 
Paris, France; phone (33) 1-47-662-419. 

Eighth International Symposium on Pro¬ 
tocol Specification, Testing, and Verification 
(IFIP), June 7-10, Atlantic City, N.J. Con¬ 
tact Sudhir Aggarwal, Bell Communications 
Research, 435 South St., Morristown, NJ 
07960; (201) 829-4477, or Krishan Sabnani, 
AT&T Bell Laboratories, 600 Mountain 
Ave., Murray Hill, NJ 07974; (201) 

582-5740. 


7TN Sixth IEEE European Workshop on 
Design for Testability, June 13-16, 

Arnitem, The Netherlands. Contact Thomas 
W. Williams, IBM Corp., 67A/021, PO Box 
1900, Boulder, CO 80301; (303) 924-7692. 


£2^ Fifth International Conference on 
'5*7 Testing Computer Software (DPMA), 
June 13-16, Washington, D.C. Contact Wil¬ 
liam Hetzel, Software Quality Engineering, 
3015 Hartley Rd., Suite 16, Jacksonville, FL 
32217; (904) 268-8639, or US Professional 
Development Institute, 1734 Elton Rd., Suite 
221, Silver Spring, MD 20903; (301) 
445-4400. 


Eighth International Conference on 
^*7 Distributed Computing Systems, June 
13-17, San Francisco. Contact Carl Davis, 
Dept, of Computer Science, University of 
Alabama, Huntsville, AL 35899; (205) 
895-6088. 


26th Assoc, for Computational Linguistics 
Meeting, June 7-10, Buffalo, N.Y. Contact 
William J. Rapaport, Dept, of Computer 
Science, State University of New York, 
Buffalo, NY 14260; (716) 636-3193. 

Symposium on Engineering of 
^*7 Computer-Based Medical Systems, 
June 8-10, Minneapolis, Minn. Contact John 
M. Long, Dept, of Surgery, University of 
Minnesota, 2829 University Ave. SE, Suite 
408, Minneapolis, MN 55414; (612) 

627-4850. 

Eighth International Conference on the 
Analysis and Optimization of Systems 
(INRIA), June 8-10, Antibes, France. Con¬ 
tact INRIA, Service des Relations Exter- 
ieures, Bureau des Colloques, Domaine de 
Voluceau, Rocquencourt, BP 105, 78153 Le 
Chesnay Cedex, France; phone 33 (1) 
39-635-600. 


£2^ DAC 88, 25th ACM/IEEE Design 
^*7 Automation Conference, June 12-15, 

Anaheim, Calif. Contact Pat Pistilli, MP 
Associates, 7490 Clubhouse Rd., Suite 102, 
Boulder, CO 90301; (303) 530-4333. 


17th Mumps Users’ Group Meeting, June 
13-17, New Orleans. Contact Mumps Users’ 
Group, 4321 Hartwick Rd., Suite 510, Col¬ 
lege Park, MD 20740; (301) 779-6555. 

Third Ada Software Engineering Education 
and Training Symposium, June 13-17, Den¬ 
ver, Colo. Contact Sue S. O’Neill, Ada 
Information Clearinghouse, IITRI, 4550 
Forbes Blvd., Suite 300, Lanham, MD 
20706;(703) 685-1477. 

^2N Third Conference on Structure in 
'5IJ' Complexity Theory, June 14-17, Wash¬ 
ington, DC. Contact Alan L. Selman, Col¬ 
lege of Computer Science, 161 CN, 360 
Huntington Ave., Boston, MA 02115; (617) 
437-8688. 

NECC 88, Ninth National Educational Com¬ 
puting Conference (ACM), June 15-17, 

Dallas. Contact NECC 88, International 
Council for Computers in Education, Uni¬ 
versity of Oregon, 1787 Agate St., Eugene, 
OR 97403-9905; (503) 686-4414; or James L. 
Poirot, Computer Science Dept., North 
Texas State University, PO Box 13886, Den¬ 
ton, TX 76203-3886; (817) 565-2818. 


Computer Security Foundations Work- 
K *7 shop, June 12-15, Franconia, N.H. 
Contact Jonathan K. Millen, Mitre Corp., 
MS B325, Burlington Rd., Bedford, MA 
01730. 

ICC 88, International Conference on Com¬ 
munications (IEEE), June 12-15, Philadel¬ 
phia. Contact Gary Ridge, Bell of Pennsyl¬ 
vania, 15th Floor, 1 Pkwy., Philadelphia, 

PA 19102; (215) 466-8709, or ICC 88, c/o 
IEEE Office, Moore School of Electrical 
Engineering, Rm. 209, University of Penn¬ 
sylvania, Philadelphia, PA 19104; (215) 
898-8106. 

Third International Workshop of the 
Bellman Continuum (INRIA), June 13-14, 

Sophia-Antipolis, France. Contact A. Bla- 
quiere, Universite de Paris VII, Laboratoire 
d’Automatique Theorique, Tour 14-24, 2 
Place Jussieu, 75251 Paris Cedex 05, France. 


IEEE International Symposium on Informa¬ 
tion Theory, June 19-24, Kobe, Japan. Con¬ 
tact Shu Lin, Dept, of Electrical Engineer¬ 
ing, University of Hawaii at Manoa, Holmes 
Hall 483, 2540 Dole St., Honolulu, HI 
96822; or Suguru Arimoto, Faculty of 
Engineering Science, Osaka University, 
Toyonaka, Osaka 560, Japan. 

£2^ 18th International Symposium on 
^*7 Fault-Tolerant Computing, June 
27-30, Tokyo. Contact Yasuo Komamiya, 
2-4-8 Kikuna, Kohoku-Ku, Yokohama 222, 
Japan; phone (81) 044-911-8181. 


© Aegean Workshop on Computing, 
June 28-July 1, Corfu Island, Greece. 
Contact John Reif, Computer Science Dept., 
Duke University, Durham, NC 27705; (919) 
684-3048. 


July 1988 


1988 International Conference on Supercom¬ 
puting (ACM, INRIA), July 4-8, Saint Malo, 
France. Contact C.D. Polychronopoulos, 
Center for Supercomputing, University of 
Illinois, 104 S. Wright St., Urbana, IL 61801 
(in North and South America); W. Jalby, 
INRIA, BP 105, 78153 Le Chesnay Cedex, 
France (in Europe, Middle East, and Africa); 
or H. Terada, Dept, of Electronic Engineer¬ 
ing, Osaka University, Yamadaoka, 2-1 
Suita, Osaka, Japan 565 (in Japan and the 
Far East). 

Conference on the Role of Artificial Intelli¬ 
gence in Databases and Information Systems 
(IFIP), July 4-8, Canton, China. Contact 
Robert Meersman, Infolab, K.U. Brabant, 
Postbus 90153, NL-5000 Le Tilburg, The 
Netherlands; phone 31 (13) 662-430. 

Eighth International Conference in Com¬ 
puter Science, July 4-8, Santiago, Chile. 
Contact Alberto O. Mendelzon, CSRI, Uni¬ 
versity of Toronto, 10 King’s College Rd., 
Toronto, Canada M5S 1A4; phone (416) 
978-2952. 


£2N Third Symposium on Logic in Com- 
'5*7 puter Science, July 5-8, Edinburgh, 
Scotland. Contact A.K. Chandra, IBM T.J. 
Watson Research Center, PO Box 218, 
Yorktown Heights, NY 10598; (914) 
945-1752. 


Second Conference on Software Engineering 
(IEE, BCS), July 11-15, Liverpool, England. 
Contact Conference Services, IEE, Savoy 
Place, London WC2R OBL, England, UK. 


£2^1 CASE 88, Second International Work- 
'5*7 shop on Computer-Aided Software 
Engineering (ACM), July 12-15, Cambridge, 
Mass. Contact Elliott Chikofsky or Pamela 
Meyer, CASE 88, c/o Index Technology 
Corp., One Main St., Cambridge, MA 
02142; (617) 494-8200, ext. 552 or 1988. 


12th IMACS World Congress on Scientific 
Computation, July 18-22, Paris. Contact 
Jean-Marc David, Laboratoires de Marcous- 
sis, Computer Science Division, Route de 
Nozay, 91460 Marcoussis, France. 

/£2^, Second Workshop on Software Test- 
V*7 ing, Verification, and Analysis, July 
19-21, Banff, Canada. Contact Lee White, 
Dept, of Computer Science, University of 
Alberta, Edmonton, Alberta, Canada T6G 
2H1; (403) 432-4589. 

International Workshop on VLSI for Artifi¬ 
cial Intelligence, July 20-22, Oxford, 
England. Contact Jose G. Delgado-Frias or 
Will R. Moore, Dept, of Engineering 
Science, University of Oxford, Parks Rd., 
Oxford, OX1 3PJ, England, UK; phone (44) 
0865-273-188. 


ICNN 88, IEEE 1988 International Confer¬ 
ence on Neural Networks, July 24-27, San 
Diego. Contact Nomi Feldman, IEEE ICNN 
88, 3770 Tansy St., San Diego, CA 92121; 
(619) 453-6222. 
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ECCE 88, European Conference on Com¬ 
puters and Education, July 24-29, Lausanne, 
Switzerland. Contact IFIP, 3 rue de Marche, 
CH-1204, Geneva, Switzerland. 


August 1988 

SIGGraph 88,15th Conference and 
'^§5' Exhibition on Computer Graphics and 
Interactive Techniques, Aug. 1-5, Atlanta. 
Contact Adele Newton, University of Water¬ 
loo, Dept, of Computer Science, Waterloo, 
Ontario, Canada N2L 3G1; (519) 888-4534. 

Third International Conference on Applica¬ 
tions of Artificial Intelligence in Engineer¬ 
ing, Aug. 8-12, Stanford, Calif. Contact R. 
Adey, Computational Mechanics Institute, 

25 Bridge St., Billerica, MA 01821; (617) 
667-7582. 

31st Midwest Symposium on Circuits and 
Systems, Aug. 11-12, St. Louis, Mo. Contact 
R. Eugene Stuffle, Dept, of Electrical 
Engineering, 317 Engineering Research 
Laboratory, University of Missouri, Rolla, 
MO 65401-0249; (314) 341-4371. 

ZZX Joint Fifth Symposium and Fifth Inter- 
757 national Conference on Logic Pro¬ 
gramming (Assoc, for Logic Programming), 
Aug. 15-19, Seattle. Contact Kenneth A. 


Bowen, LP88, Logic Programming Research 
Group, School of Computer and Information 
Science, 313 Link Hall, Syracuse University, 
Syracuse, NY 13210; (315) 423-2466/67. 

ICPP 17, 17th International Conference on 
Parallel Processing, Aug. 15-19, St. Charles, 
Ill. Contact David H. Bailey, MS 258-5, 
NASA Ames Research Center, Moffett 
Field, CA 94035; Howard E. Sturgis, Xerox 
Corp., Palo Alto Research Center, 3333 
Coyote Hill Rd., Palo Alto, CA 94304; or 
Faye A. Briggs, Sun Microsystems, 2550 
Garcia Ave., Mountain View, CA 94043. 

DIAC 88, Directions and Implications of 
Advanced Computing Symposium (CPSR), 
Aug. 21, St. Paul, Minn. Contact Doug 
Schuler, Computer Professionals for Social 
Responsibility, PO Box 717, Palo Alto, CA 
94301;(206)865-3226. 

ZZX Crypto 88 (IACR), Aug. 21-25, Santa 
*757 Barbara, Calif. Contact Harold 
Fredricksen, Mathematics Dept., Code 53Fs, 
Naval Postgraduate School, Monterey, CA 
93943; (408) 646-2206. 


CAD/CAM Technology Transfer to Latin 
America Conference (IFIP), Aug. 22-26, 

Mexico City. Contact Instituto de Investiga- 
ciones Electricas, Apdo. Postal 5-849, 11590 
Mexico, D.F. 


Coling 88, 12th International Conference on 
Computational Linguistics, Aug. 22-27, 

Budapest, Hungary. Contact Coling 88 
Secretariat, Mtesz Congress Bureau, H-1055 
Budapest, Kossuth ter. 6-8, Hungary. 

LFA 88, Sixth IEEE Workshop on 
^57 Languages for Automation, Aug. 
29-31, College Park, Md. Contact Panos A. 
Ligomenides, Electrical Engineering Dept., 
University of Maryland, College Park, MD 
20742; (301)454-6842. 

14th International Conference on Very 
757 Large Databases (VLDB Endowment), 
Aug. 29-Sept. 1, Los Angeles. Contact Jack 
E. Shemer, Teradata Corp., 12945 Jefferson 
Blvd., Los Angeles, CA 90066; (213) 
827-8777. 

EuroMicro 88, 14th Symposium on 
Microprocessing and Microprogramming, 
Aug. 29-Sept. 1, Zurich. Contact EuroMicro 
88, PO Box 545, 7500 AM Enschede, The 
Netherlands; phone (31) 53-338-799. 

ICO Topical Meeting on Optical Com- 
puting, Aug. 30-Sept. 2, Orsay, 

France. Contact S. Lowenthal, Insitut D’Up- 
tique, BP 43, 91406 Orsay Cedex, France. 

ITC 88, 1988 International Test Con- 
757 ference, Aug. 30-Sept. 2, Washington, 
DC. Contact ITC 88, Computer Society, 

1730 Massachusetts Ave. NW, Washington, 
DC 20036-1903; (202) 371-1013. 
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September 1988 

ZZ^ International Neural Networks Society 
*5*7 Annual Meeting, Sept. 6-10, Boston. 
Contact Mark Kon, Dept, of Mathematics, 
Boston University, 111 Cummington St., 
Boston, MA 02115; (617) 353-2762. 

1988 International Test Conference, 
*5*7 Sept. 12-14, Washington, D.C. Con¬ 
tact Doris Thomas, ITC, PO Box 264, Mt. 
Freedom, NJ 07970; (201) 895-5260. 

NCGA Mapping and Geographic Informa¬ 
tion Systems 88, Sept. 12-15, Orlando, Fla. 
Contact NCGA, National Computer 
Graphics Assoc., 2722 Merrilee Dr., Suite 
200, Fairfax, VA 22031. 

Eurographics 88, Ninth European Assoc, for 
Computer Graphics Conference (INRIA), 
Sept. 12-16, Nice, France. Contact INRIA, 
Service des Relations Exterieures, Domaine 
de Voluceau, BP 105, 78153 Le Chesnay 
Cedex, France; phone (33) 1-39-635-501. 

/SN Fourth International Conference of 
*^7 Modeling Techniques and Tools for 
Computer Performance Evaluation, Sept. 
15-17, Palma de Mallorca, Spain. Contact 
Ramon Puigjaner, UIB, Miguel dels Sants 
Oliver 2, 07012 Palma de Mallorca, Spain; 
phone (34) 71-725-706. 

ZZN IEEE Artificial Neural Networks Con- 
ference, Sept. 18-21, Reston, Va. Con¬ 
tact Kamal Karma, 823 Flegler Rd., 
Gaithersburg, MD 20879; (301) 984-7657. 

Fourth International Symposium on Biologi¬ 
cal and Artificial Intelligence Systems, Sept. 

18- 22, Trento, Italy. Contact Alberta Mar¬ 
tino, IBM Corp., Dept. 48B/428, Neighbor¬ 
hood Rd., Kingston, NY 12401; (914) 
385-4964. 

Conference on Computerized Assistance 
During System Life Cycle (1FIP), Sept. 

19- 22, London. Contact International Feder¬ 
ation for Information Processing, 3 rue de 
Marche, CH-1204, Geneva, Switzerland. 

Workshop and Symposium on Formal Tech¬ 
niques in Real-time and Fault-tolerant Sys¬ 
tems, Sept. 20-23, Coventry, England, UK. 
Contact M. Joseph, Dept, of Computer 
Science, University of Warwick, Coventry, 
CV4 7AL, UK. 

First International Workshop on 
Transaction Machine Architecture, 
Sept. 25-28, Lake Arrowhead, Calif. Con¬ 
tact Martin Freeman, Signetics Corp., 811 E. 
Arques Ave., Sunnyvale, CA 94086; (408) 
991-3591. 

ZZ^ Computational Intelligence 88, Sept. 
5*7 26-30, Milano, Italy. Contact Giorgio 
Valle, Universita di Milano, Dip. di Sciencze 
dell’Informazione, Via Moretto 9, 20133 
Milano, Italy; phone (39) 02-2772-228. 

ZZ^ Second International Workshop on 
5*7 Object-Oriented Programming Data¬ 
base Systems (ACM), Sept. 27-30, Bad 


Muensteram Stein-Ebernburg, Germany. 
Contact Alex Buchmann, CCA, Four Cam¬ 
bridge Center, Cambridge, MA 02142; (617) 
492-8860. 

26th Allerton Conference on Communica¬ 
tion, Control, and Computing, Sept. 28-30, 

Monticello, Ill. Contact Allerton Confer¬ 
ence, c/o Mark W. Spong, University of 
Illinois at Urbana-Champaign, Coordinated 
Science Laboratory, 1101 W. Springfield 
Ave., Urbana, IL 61801; (217) 333-4281. 


October 1988 

ICCD 88, IEEE International Confer- 
5*7 ence on Computer Design, Oct. 2-6, 
Rye Brook, N.Y. Contact ICCD 88, Com¬ 
puter Society, 1730 Massachusetts Ave. NW, 
Washington, DC 20036-1903; (202) 

371-1013. 

^Z^ Compsac 88, 12th International Com- 
'5*7 puter Software and Applications Con¬ 
ference, Oct. 3-7, Chicago. Contact Wing N. 
Toy, Compsac 88, AT&T Bell Laboratories, 
Rm. 1Z-306, 200 Park Plaza, Naperville, IL 
60566; (312) 416-4046, or Computer Society, 
1730 Massachusetts Ave. NW, Washington, 
DC 20036-1903; (202) 371-1013. 

1988 International Display Research Confer¬ 
ence (IEEE, SID), Oct. 4-6, San Diego, 

Calif. Contact Palisades Institute for 
Research Services, Attn. IDRC, 201 Varick 
St., New York, NY 10014; (212) 620-3388. 

International Workshop on Defect and 
'5*7 Fault Tolerance in VLSI Systems, Oct. 
6-7, Springfield, Mass. Contact Israel Koren, 
Dept, of Electrical and Computer Engineer¬ 
ing, University of Massachusetts, Amherst, 
MA 01003; (413) 545-2643. 

NCGA CAD/CAM 88, Oct. 9-12, Boston. 
Contact NCGA CAD/CAM 88, National 
Computer Graphics Assoc., 2722 Merrilee 
Dr., Suite 200, Fairfax, VA 22031. 

ICCL 88, International Conference on 
*^p* Computer Languages, Oct. 9-13, 

Miami Beach, Fla. Contact Pei Hsia, Com¬ 
puter Science, University of Texas, 2100 Oak 
Bluff Dr., Arlington, TX 76001; (817) 
273-3785. 

Z2N Seventh Symposium on Reliable Dis- 
'5*7 tributed Systems, Oct. 10-12, 

Columbus, Ohio. Contact Ming T. Liu, 
Dept, of Computer and Information 
Science, Ohio State University, 2036 Neil 
Ave., Columbus, OH 43210-1277; (614) 
292-1837, or David Cohen, Tekuekron 
Infoswitch, 1784 Firman Dr., Richardson, 
TX 75081. 

ZZ^ 1988 IEEE Workshop on Visual Lan- 
5*7 guages, Oct. 10-12, Pittsburgh. Con¬ 
tact Erland Jungert, Dept, of Computer 
Science, University of Pennsylvania, Pitts¬ 
burgh, PA 15260; Alfs T. Berztiss, Com¬ 
puter Science Dept., Faculty of Arts and 
Sciences, University of Pittsburgh, 322 


Alumni Hall, Pittsburgh, PA 15260; or 
Stefano Levialdi, Departimento di Matemat- 
ica, Universita di Roma, Piazzale A. Moro, 
00185, Rome, Italy. 

ZZ^ 13th Conference on Local Computer 
*5*7 Networks, Oct. 10-12, Minneapolis, 
Minn. Contact Ron Rutledge, MS-271, Mar¬ 
tin Marietta Energy Systems, Oak Ridge 
National Laboratory, Oak Ridge, TN 37831; 
(615) 576-7643. 

Frontiers 88, Second Symposium on 
*^p* the Frontiers of Massively Parallel 
Computation, Oct. 10-12, Fairfax, Va. Con¬ 
tact Frontiers 88 Symposium, PO Box 334, 
Greenbelt, MD 20770-0334. 

International Workshop on Computer 
Vision (IAPR), Oct. 12-14, Tokyo. Contact 
Mikio Takagi, Institute of Industrial 
Science, University of Tokyo, 7-22-1, Rop- 
pongi, Minato-ku, Tokyo 106, Japan; phone 
(81)3-479-0289. 

ACM SIGGraph Symposium on User Inter¬ 
face Software, Oct. 17-19, Banff, Canada. 
Contact John Sibert, Dept, of Electrical 
Engineering and Computer Science, George 
Washington University, Washington, DC 
20052; (202) 994-4953. 

Ninth International Conference on Pattern 
Recognition (IAPR), Oct. 17-20, Beijing. 
Contact Secretariat, Chinese Assoc, of Auto¬ 
mation, PO Box 2728, Beijing, China. 

® ESIG 88, Fourth Expert Systems in 
Government Conference, Oct. 17-21, 

Washington, DC. Contact ESIG 88, Com¬ 
puter Society, 1730 Massachusetts Ave. NW, 
20036-1903; (202)371-1013. 

Third International Symposium on Knowl¬ 
edge Engineering (AAAI), Oct. 17-21, 

Madrid, Spain. Contact Jose R. Chelala, 
Third International Symposium on Knowl¬ 
edge Engineering, Alvarez de Baena, 3-2, 
28006 Madrid, Spain. 

ZZN CSM 88, Conference on Software 
5*7 Maintenance—1988 (DPMA, NBS), 
Oct. 24-27, Phoenix, Ariz. Contact Robert 
Arnold, Software Productivity Consortium, 
1880 Campus Commons Dr. North, Reston, 
VA 22091; (703) 391-1898. 

ZZ^ Second International Software for 
*5*7 Strategic Systems Conference, Oct. 
25-26, Huntsville, Ala. Contact Karen 
B. Mack, University of Alabama, Division 
of Continuing Education, Tom Bevill Cen¬ 
ter, Huntsville, AL 35899; (205) 895-6357. 

IECON 88 (IEEE), Oct. 25-27, Singapore. 
Contact V.K.L. Huang, AT&T Information 
Systems, Crawford Corners Rd., Holmdel, 
NJ 07733; (210) 949-0069. 

7T\ Ninth IEEE Symposium on Mass Stor- 
*5*7 age Systems, Oct. 30-Nov. 3, Mon¬ 
terey, Calif. Contact Patric Savage, Shell 
Development Co., PO Box 481, Houston, 
TX 77001; (713) 663-2384. 
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ICCC 88, Ninth International Conference on 
Computer Communication (IEEE Israel Sec¬ 
tion), Oct. 30-Nov. 3, Tel Aviv, Israel. Con¬ 
tact J. Kella, Secretariat, PO Box 50006, Tel 
Aviv 61500, Israel; phone (972) 03-654-571. 


22nd Asilomar Conference on Signals, 
5*7 Systems, and Computers (IEEE, Naval 
Postgraduate School), Oct. 31-Nov. 2, 

Pacific Grove, Calif. Contact Douglas 
Elliott, Rockwell International, 3370 Mira- 
loma Ave., Mail Stop BD07, Anaheim, CA 
92803-317; (714) 762-2340. 


ICCS 88, International Conference on Com¬ 
munication Systems (IEEE), Oct. 31-Nov. 3, 
Singapore. Contact ICCS 88, c/o Meeting 
Planners Pte Ltd., 100 Beach Rd„ #33-04, 
Shaw Towers, Singapore 0718. 


November 1988 

1988 Workshop on VLSI Signal Processing, 
Nov. 2-4, Monterey, Calif. Contact Paulette 
Powell, Electronics Research Laboratory, 
University of California, Berkeley, CA 
94720; (415) 642-1566. 


Third Workshop on Knowledge Acquisition 
for Knowledge-Based Systems (AAAI), Nov. 
7-11, Banff, Canada. Contact John H. 
Boose, Advanced Technology Center, Boe¬ 
ing Computer Services, MS 7L-64, PO Box 
24346, Seattle, WA 98124; (206) 865-3253. 


Second International Symposium on 
5*7 Interoperable Information Systems, 
Nov. 10-11, Tokyo. Contact Hideo Aiso, 
Dept, of Electrical Engineering, Keio Uni¬ 
versity, 3-14-1, Hiyoshi, Kohoku-ku, Yoko¬ 
hama, Karagawa, 223 Japan; (81) 
044-631-141, ext. 3320. 


tin Supercomputing 88, Nov. 14-18, 

5*7 Orlando, Fla. Contact George 
Michael, L-306, Lawrence Livermore 
National Laboratory, PO Box 808, Liver¬ 
more, CA 94550; (415) 422-4239. 


Fourth Conference on Artificial Intelligence 
for Space Applications (NASA), Nov. 15-16, 
Huntsville, Ala. Contact Conference on 
Artificial Intelligence for Space Applica¬ 
tions, NASA/EB44, MSFC, AL 35812; (205) 
544-5181. 


® ICCAD 88, IEEE International Con¬ 
ference on Computer-Aided Design 
(ACM) Nov. 7-10, Santa Clara, Calif. Con¬ 
tact A1 Jimenez, Mentor Graphics Corp., 
1940 Zanker Rd., San Jose, CA 95112; (408) 
436-1500. 


AIDA 88, Fourth Conference on Artificial 
Intelligence and Ada, Nov. 15-16, Washing¬ 
ton, D.C. Contact Jorge Diaz-Herrera, 
Computer Science Dept., George Mason 
University, 400 University Dr., Fairfax, VA 
22030;(703)323-2713. 


Sixth CIPS Edmonton Computer Confer¬ 
ence, Nov. 15-17, Edmonton, Canada. Con¬ 
tact U. M. Maydell, Dept, of Computing 
Science, University of Alberta, Edmonton, 
Alberta, T6G 2H1, Canada. 


Wescon 88 (IEEE), Nov. 15-17, Anaheim, 
Calif. Contact Wescon 88, c/o Electronic 
Conventions Management Educational 
Activities Dept., 8110 Airport Blvd., Los 
Angeles, CA 90045; (213) 772-2965. 


Micro 21, Workshop on Micropro- 
5*7 gramming and Microarchitecture 
(ACM), Nov. 28-Dec. 1, San Diego, Calif. 
Contact Yale N. Patt, Computer Science 
Division, 573 Evans Hall, University of 
California, Berkeley, CA 94720; (415) 
642-4829. 


Globecom 88, IEEE Global Telecommunica¬ 
tions Conference, Nov. 28-Dec. 1, Holly¬ 
wood, Fla. Contact Ray R. Laane, Bell 
Communications Research, 435 South St., 
Rm. 2F-287, Morristown, NJ 07960; (201) 
829-4064. 


Z2S FGCS 88, International Conference on 
*5*7 Fifth Generation Computer Systems, 
Nov. 28-Dec. 2, Tokyo. Contact Hideo Aiso, 
Dept, of Electrical Engineering, Keio Uni¬ 
versity, 3-14-1, Hiyoshi, Kohoku-ku, Yoko¬ 
hama, Karagawa, 223 Japan; (81) 
044-631-141, ext. 3320. 


-IEEE WORKSHOP ON VISUAL MOTION - 
Irvine, California 
March 20-22, 1989 


The workshop will bring together researchers from computer vision, artificial intelligence, and psychophysics 
to discuss current work on the representation and analysis of motion in image sequences. Papers axe invited 
on all aspects of the analysis of motion in human and machine vision. The number of presentations will be 
limited to increase time for discussion. Authors are encouraged to present new computational methods with 
experimental results, theoretical results that offer significant new insights into problem solutions, or to relate 
experimental observations on human .visual processing to the underlying computational strategies used. 

Submission of Papers: Submit three copies of the paper to either Ellen Hildreth or Ramesh Jain on 
or before July 15, 1988. The papers should not exceed 25 double spaced pages. Authors will be notified of 
the decisions by October 15, 1988. Final papers will be required by the Computer Society of the IEEE on 
November 25, 1988. 


General Chairman: Brian G. Schunck 
Local Arrangements: 

M.L. Braunstein and D.D. Hoffman 
Program Committee: 

Ted Adelson, John Aloimonos 
Rama Chellappa, Allen Jepson 
H.-H. Nagel, Ken Nakayama 
Bill Thompson, Allen Waxman 


Program Chairs: 

Ellen Hildreth 

Artificial Intelligence Laboratory 
545 Technology Square 
Cambridge, MA 02139 
and 

Ramesh Jain 

Electrical Engineering and Computer Science 
The University of Michigan 
Ann Arbor, MI 48109-2122 


^ THE INSTITUTE OF ELECTRICAL 












CALL FOR PAPERS 


Call for papers and referees for Computer 


Computer seeks articles for inclusion in 
several upcoming special issues. 

Real Machines: Design Choices/Engineering 
Trade-offs is the theme scheduled for the 
January 1989 issue. 

Suggested topics include, but are not limited 


• the microarchitecture structures used and 
their cost benefit trade-offs; 

• the influence of technology on the architec¬ 
ture, design, and implementation; 

• the influence of higher-level structures (for 
instance, multiprogramming languages, 
multiprocessors, attach processors); 

• the influence of design complexity vis-a-vis 
time to market; 

• the importance of historical products; and 

• the importance of competitive products. 

Papers must not have been previously pub¬ 
lished or currently submitted for publication 
elsewhere. 

Eight copies of the full manuscript are due 
by May 15, 1988 and should be submitted to 
Yale N. Patt, Computer Science Division, 
Department of Electrical Engineering and 
Computer Science, 573 Evans Hall, Univer¬ 
sity of California, Berkeley, CA 94720; (415) 
642-4829; e-mail: patt@ji.berkeley.edu. 

Authors will be notified of acceptance by 
Aug. 15, 1988. The final version of the man¬ 
uscript is due no later than Oct. 15,1988. 

Persons interested in serving as referees are 
asked to send a note and a list of technical 
interests to Yale Patt or to Bruce D. Shriver, 


Computer Editor-in-Chief, IBM T.J. Wat¬ 
son Research Center, PO Box 704, Yorktown 
Heights, NY 10598; e-mail: shriver@ibm.com. 


Robotics and Automation is the theme slated 
for the March 1989 issue. 

The manuscript should be submitted by July 
1, 1988 to Gordon T. Wilfong, AT&T Bell 
Laboratories, 600 Mountain Ave., Murray 
Hill, NJ 07974; (201) 582-3561; csnet: 
gtwVoresearch.att.com@relay.cs.net, or to 
Varol Akman, Center for Mathematics and 
Computer Science, Kruislaan 413, 1098 SJ 
Amsterdam, The Netherlands; phone 
31-20-592-4144; csnet: mcvaxlcwi.nil varol @ 
seismo.css.gov. 

Software Tools for Hardware Test is the 

theme scheduled for the April 1989 issue. 


Autonomous Intelligent Machines is the 

theme scheduled for the June 1989 issue. 

Suggested topics include 

• path planning and navigation; 

• learned autonomous machines; 

• robot vision and sensing; 

• distributed and parallel architectures for 
intelligent machines; 

• multisensor integration for intelligent 
machine applications; 

• real-time control and coordination of 
mobile robots and manipulators; 

• machine intelligence and expert systems; 

• robot programming. 

Papers must not have been previously pub¬ 
lished or currently submitted for publication 
elsewhere. 


Submit the manuscript by July 1,1988 to 
Scott Davidson, AT&T Engineering 
Research Center, PO Box 900, Princeton, NJ 
08540; Princeton office (609) 639-2289; 
Holmdel office (609) 639-6310; Compmail +: 
s.davidson. 


Rapid Prototyping is the theme slated for the 
May 1989 issue. 

Submit the manuscript by Sept. 1, 1988 to 
Murat M. Tanik, Department of Computer 
Science, School of Engineering and Applied 
Science, Southern Methodist University, 
Dallas, TX 75275-0122; (214) 692-2854; 
csnet: smu.tanik@uunet.uu.net, or to Ray¬ 
mond T. Yeh, ISSI International, 9420 
Research Blvd., Suite 2000, Austin, TX 
78759; (512) 338-1895; csnet: issi@emx. 


A 300-word abstract should be submitted as 
soon as possible. Eight copies of the full 
manuscript must be submitted by Oct. 1, 

1988 to S. Sitharama Iyengar, Department of 
Computer Science, Louisiana State Univer¬ 
sity, Baton Rouge, LA 70803-4020; (504) 
388-1495; csnet: iyengar%lsu.edu@ 
relay.csnet, or to Rangasami L. Kashyap, 
Department of Electrical Engineering, Pur¬ 
due University, West Lafayette, IN 47907; 
(317) 494-3473; csnet: kashyap@473; csnet: 
@ee.ecn.purdue.edu. 

Authors will be notified of acceptance by 
Jan. 10, 1989. The final version of the manu¬ 
script is due no later than Feb. 25, 1989. 

Persons interested in serving as referees are 
asked to send a note to Iyengar or Kashyap 
with a list of technical interests. 


The Journal of Computing and Society will 
begin publication in 1989. Submit articles to 
Gary Chapman, Computer Professionals for 
Social Responsibility, PO Box 717, Palo 
Alto, CA 94301. 


IEEE Conference on Neural Information 
Processing Systems: Nov. 28-Dec. 1, 1988, 
Denver, Colo. Submit paper by May 14, 

1988 to Scott Kirkpatrick, IBM T.J. Watson 
Research Center, PO Box 704, Yorktown 
Heights, NY 10598. 


ICCV 88, Second International Con¬ 
ference on Computer Vision: Dec. 5-8, 
1988, Tarpon Springs, Fla. Submit paper by 
May 15, 1988 to Ruzena Bajcsy, University 
of Pennsylvania, Dept, of Computer and 
Information Science, 200 S. 33rd St., 
Philadelphia, PA 19104-6389; (215) 
898-6222. 


International Workshop on Computer 
Vision (IAPR): Oct. 12-14, 1988, Tokyo. 
Submit summary by May 15, 1988 and final 
paper by Aug. 31, 1988 to Mikio Takagi, 
Institute of Industrial Science, University of 
Tokyo, 7-22-1, Roppongi, Minato-ku, 
Tokyo 106, Japan; phone (81) 3-479-0289. 


Z2N Conferences that the Computer Society sponsors or participates in are indicated 
by the Computer Society logo; additional conference sponsors are listed in paren¬ 
theses. Other conferences of interest to our readers are also included. 

For inclusion in Call for Papers or Calendar, submit information six weeks before the 
month of publication (i.e., for the July 1988 issue, send information for receipt by 
May 15, 1988) to Calendar Editor, Computer, 10662 Los Vaqueros Cir., Los 
Alamitos, CA 90720. 
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Third Workshop on Knowledge Acquisition 
for Knowledge-Based Systems (AAAI): Nov. 
7-11, 1988, Banff, Canada. Submit abstract 
or complete paper by May 15, 1988 to John 
H. Boose, Advanced Technology Center, 
Boeing Computer Services, MS 7L-64, PO 
Box 24346, Seattle, WA 98124; (206) 

865-3253. 

Fourth National Convention of Computer 
Engineers (Institution of Engineers—India): 

December 1988, Calcutta, India. Submit 
paper by May 15, 1988 to Anirban Basu, 
Fourth National Convention of Computer 
Engineers, West Bengal State Center, 8, 
Gokhale Rd., Calcutta-700 020, India. 

1988 Rochester Forth Conference on Pro¬ 
gramming Environments: June 14-18, 1988, 
Rochester, N.Y. Submit abstract by May 15, 
1988 and paper by June 1, 1988 to Lawrence 
P. Forsley, Institute for Applied Forth 
Research, 70 Elmwood Ave., Rochester, NY 
14611; (716)328-6426. 

Eighth Conference on Foundations of Soft¬ 
ware Technology and Theoretical Computer 
Science: Dec. 21-23, 1988, Pune, India. Sub¬ 
mit paper by May 16, 1988 K.V. Nori, 
TRDDC, 1 Mangaldas Rd., Pune 411001, 
India; phone (212) 61608. 

Tax Fourth Aerospace Computer Security 
*55? Applications Conference: Dec. 12-16, 
1988, Orlando, Fla. Submit paper by May 
20, 1988 to William T. Bisignani, Booz-Allen 
& Flamilton, Inc., 4330 East-West Flwy., 
Bethesda, MD 20814. 

Symposium on Computer Graphics Educa¬ 
tion: Nov. 4-5, 1988, Poughkeepsie, N.Y. 
Submit paper by May 31, 1988 to Marek 
Holynski, Boston University, 111 Cumming- 
ton St., Boston, MA 02215. 

XjX IEEE Software: January 1989. Articles 
* 55 ? are sought on human-computer inter¬ 
faces, human factors, and user issues. Sub¬ 
mit articles by June 1, 1988 to Deborah Hix, 
Guest Editor, Computer Science Dept., Vir¬ 
ginia Polytechnic Institute, Blacksburg, VA 
24061; (703) 961-4857, or Ted G. Lewis, 
Editor-in-Chief, IEEE Software c/o Com¬ 
puter Science Dept., Oregon State Univer¬ 
sity, Corvallis, OR 97331; (503) 754-2744; 
CSnet lewis@oregon-state; Compmail + 
t.lewis. 

® 22nd Asilomar Conference on Signals, 
Systems, and Computers (IEEE, Naval 
Postgraduate School): Oct. 31-Nov. 2, 1988, 
Pacific Grove, Calif. Submit abstract and 
paper by June 1, 1988 to John T. Rickard, 
Orincon Corp., 3366 N. Torrey Pines Ct., 
Suite 300, La Jolla, CA 92037; (619) 
455-5530. 

TJX Compcon Spring 89: Feb. 27-Mar. 3, 
*55? 1989, San Francisco. Submit paper by 
June 1, 1988 to Kenichi Miura, Computa¬ 
tional Research Dept., Mail Stop B2-7, 
Fujitsu America, Inc. 3055 Orchard Dr., San 
Jose, CA 95134-2017; (409) 432-1300, ext. 
5408 or 5723. 


T2X 1988 International Computer Science 
'§7 Conference: Dec. 19-21, 1988, Flong 
Kong. Submit paper by June 15, 1988 to 
Jean-Louis Lassez, IBM T.J. Watson 
Research Center, PO Box 218, Yorktown 
Heights, NY 10598, or Francis Y.L. Chin, 
Center of Computer Studies and Applica¬ 
tions, University of Hong Kong, Hong 
Kong. 

T2X Fifth International Conference on 
*55? Data Engineering: Feb. 7-9, 1989, Los 
Angeles. Submit paper by June 15, 1988 to 
Richard L. Shuey, Computer Science Dept., 
Rensselaer Polytechnic Institute, Troy, NY 
12189-3590; (518) 276-8376 or (518) 

374-5684. 

IFIP TC-2 Working Conference on Visual 
Database Systems (IPSJ): Apr. 3-7, 1989, 
Tokyo. Submit paper by June 15, 1988 to 
IFIP TC-2 Working Conference, Tosiyasu 
L. Kunii, Dept, of Information Science, 
Faculty of Science, University of Tokyo, 

7-3-1 Hongo, Bunkyo-ku, Tokyo 113, 

Japan; phone (81) 03-812-2111, ext. 4116. 

AIDA 88, Fourth Conference on Artificial 
Intelligence and Ada: Nov. 15-16, 1988, 
Washington, D.C. Submit paper by June 24, 
1988 to John Moore, Software Productivity 
Consortium, 1880 Campus Commons Dr. 
North, Reston, VA 22091; (703) 391-1729. 

Proceedings of the IEEE : January 1990. A 
special issue on state-of-the-art surveys on 
supercomputing technology is planned. Sub¬ 
mit paper or proposal by June 30, 1988 to 
Tse-yun Feng or A.R. Hurson, E.E. East 
Bldg., Pennsylvania State University, Uni¬ 
versity Park, PA 16802; (814) 863-1469 or 
1187. 

IEEE Transactions on Computers (IEEETC): 
April 1989. Papers are sought for a special 
issue on high-yield VLSI systems. Submit 
manuscript by July 1, 1988 to Israel Koren, 
Dept, of Electrical and Computer Engineer¬ 
ing, 210 Marcus Hall, University of Mas¬ 
sachusetts, Amherst, MA 01003; (413) 
545-2643. 

Second International Workshop on Artificial 
Intelligence in Economics and Management 
(IFIP, IFAC, IFORS): Jan. 11-13, 1989, Sin¬ 
gapore. Submit extended abstract by July 1, 
1988 to Vicky Toh, Institute of Systems 
Science, National University of Singapore, 
Kent Ridge, Singapore 0511. 

TJX Micro 21, Workshop on Micropro- 
'5*7 gramming and Microarchitecture 

(ACM): Nov. 28-Dec. 1, 1988, San Diego, 
Calif. Submit paper by July 1, 1988 to Yale 
N. Patt, Computer Science Division, 573 
Evans Hall, University of California, Ber¬ 
keley, CA 94720; (415) 642-4829. 

TJX IEEE Workshop on Visual Motion: 

*5j7 Mar. 20-22, 1989, Irvine, Calif. Submit 
paper by July 15, 1988 to Ellen Hildreth, 
Artificial Intelligence Laboratory, 545 Tech¬ 
nology Square, Cambridge, MA 02139, or 
Ramesh Jain, Electrical Engineering and 
Computer Science Dept., University of 
Michigan, Ann Arbor, MI 48109-2122. 


26th Allerton Conference on Communica¬ 
tion, Control, and Computing: Sept. 28-30, 
1988, Monticello, Ill. Submit paper and 
extended abstract by July 15, 1988 to Aller¬ 
ton Conference, c/o Mark W. Spong, Uni¬ 
versity of Illinois at Urbana-Champaign, 
Coordinated Science Laboratory, 1101 W. 
Springfield Ave., Urbana, IL 61801; (217) 
333-4281. 


ICS 88, 1988 International Computer Sym¬ 
posium: Dec. 20-21, 1988, Taipei, Taiwan. 
Submit paper by July 15, 1988 to Louis R. 
Chow, Tamkang University, Tamsui, Tai¬ 
wan, Republic of China (for authors in the 
Far East) or to Shi-Kuo Chang, Dept, of 
Computer Science, University of Pittsburgh, 
Pittsburgh, PA 15260 (for authors outside 
the Far East). 

tjx IEEE Software: March 1989. Articles 
*55? are sought for a special issue on soft¬ 
ware technology in the Far East. Submit 
manuscripts by Aug. 1, 1988 to Carl Chang, 
Guest Editor, EECS Dept., MC 154, Univer¬ 
sity of Illinois, PO Box 4348, Chicago, IL 
60680;(312)996-4860. 

IEEE Infocom 89, Conference on 
Computer Communications: Apr. 

24-27, 1989, Ottawa, Canada. Submit paper 
by Aug. 1, 1988 to J.W. Mark, IEEE Info¬ 
com 89, Dept, of Electrical Engineering, 
University of Waterloo, Waterloo, Ontario, 
Canada N2L 3G1; (519) 888-4016. 

TJX ASPLOS III, Third International Con- 
*557 ference on Architectural Support for 
Programming Languages and Operating Sys¬ 
tems (ACM): Apr. 3-6, 1989, Boston. Sub¬ 
mit paper by Aug. 1, 1988 to John Hennessy, 
Center for Integrated Systems, Stanford 
University, Stanford, CA 94305. 

ETC 89, First European Test Conference 

(SEE): Apr. 12-14, 1989, Paris. Submit 
paper by Aug. 1, 1988 to ETC 89, 48 Rue de 
la Procession, 75724 Paris Cedex 15, France. 

TJX CompEuro 89, International Conference 
*557 on VLSI and Computer Peripherals: 

May 8-12, 1989, Hamburg. Submit paper by 
Aug. 15, 1988 to Walter E. Proebster, IBM 
Laboratory, PO Box 1380, D-7030 Boeb- 
linger, Federal Republic of Germany. 

IEEE Software: May 1989. Articles are 
* 55 ? sought for a special issue on verifica¬ 
tion and validation. Submit articles by Sept. 
1, 1988 to Dolores Wallace, National Bureau 
of Standards, B-266 Technology Bldg., 
Gaithersburg, MD 20899; (301) 975-3340, or 
Robert Fujii, Logicon, 355 W. Fifth St., San 
Pedro, CA 90733; (213) 831-0611. 

TJX 11th International Conference on Soft- 
*51? ware Engineering (ACM): May 15-18, 
1989, Pittsburgh. Submit paper by Sept. 15, 
1988 to Richard Fairley, School of Informa¬ 
tion Technology, George Mason University, 
Fairfax, VA 22030, or Dines Bjorner, Dansk 
Datamatik Center, Lundtoftevej 1 C, 

Lyngby DK-2800, Denmark. 
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BOOK REVIEWS 


Editor: Wiley McKinzie, School of Computer Science and Technology, Rochester Institute of Technology, Rochester, NY 14623; Compmail, w.mckinzle; CSnet, wrm@rit 


Design of Office Information Systems 


C.A. Ellis and N. Naffah (Springer- 

Verlag, New York, 1987, 248 pp., 

$35.50) 

“The goal of this book is to present a 
framework within which the myriad of 
office technologies and office systems 
design techniques can be better under¬ 
stood.” So starts the preface for this 
promising book. Ellis and Naffah cer¬ 
tainly have the credentials to produce a 
book written “by technical computer 
people for technical computer people” 
on the technology driving office auto¬ 
mation. Ellis was formerly head of the 
office research group at the Xerox Palo 
Alto Research Center, and Naffah was 
head of the Kayak office research proj¬ 
ect in the French government’s Institute 
Nationale de la Recherche en Informa- 
tique et Automatique. This book could 
have been a dream come true for those 
interested in the technology behind 
today’s and tomorrow’s office informa¬ 
tion systems. 

Unfortunately, the book does not live 
up to its potential. I would encourage 
any publisher offered the current text as 
a proposed manuscript to fight for the 
rights. But while nicely bound and 
beautifully typeset, the book really is 
only a draft. The authors composed, 
edited, and output the text and dia¬ 
grams in camera-ready form, but 
neglected some of the final phases of 
book preparation. Some of the over¬ 
sights, such as using dithered, scanned 
images for photographs rather than 
halftone screens, are merely annoying. 
Far more critical is the lack of technical 
review, which allowed outdated exam¬ 
ples and occasional technical errors to 
appear in the final text, and the failure 
to include an index or even a detailed 
table of contents. As a result, this book 
is not the first-class reference work the 
authors are qualified to write. 

The authors start out strong in Chap¬ 
ter 1, building an office interconnect 
model and a layered workstation 
model. In Chapter 2, “Workstation 
Technology,” they discuss the compo¬ 
nents that provide a computing environ¬ 
ment for the end user, including 


processors, memories, input-output 
facilities, and peripherals from daisy- 
wheel printers to optical disks. The dis¬ 
cussion ranges from a look at the differ¬ 
ences between a personal computer and 
a terminal to European standards for 
ergonomic keyboard design. Here also 
is the first example of the lack of tech¬ 
nical review: “The floppy disk, more 
properly called the flexible disk, con¬ 
sists of a flexible sheet of plastic mate¬ 
rial with a magnetic coating and 
grooves (or frequently rails) arranged in 
concentric circles (called tracks).” 

While the phonograph record analogy is 
popular for describing floppy disks in 
elementary texts, a technical review 
should have eliminated the implication 
that a floppy disk is anything but per¬ 
fectly flat. 

Chapter 3, “Communication Tech¬ 
nology,” takes a similar approach to 
data communications. Starting with 
basic terminology such as half duplex, 
ASCII, and serial transmission, the 
chapter builds the ISO model layer by 
layer, then shows how it relates to real- 
world networking using IBM SNA and 
Xerox XNS as examples. This is the 
first evidence of an annoying trend in 
the authors’ selection of examples. 

Many of the detailed technology exam¬ 
ples are of late-1970s Xerox PARC 
work rather than more recent, more 
relevant technology. 

This becomes particularly noticeable 
in Chapter 4, “Networks.” Ten pages 
are devoted to a detailed description of 
Ethernet hardware, as you would expect 
given Ellis’ Xerox background. How¬ 
ever, the obsolete 3-Mbps precursor is 
described rather than the commercial 
standard 10-Mbps version. The other 
example of a network physical layer is a 
mere 3‘A pages on IBM Token Ring 
physical implementation and media 
access control, even though many 
analysts expect this cable plant, which is 
also the IEEE 802.5 standard, to make 
up the majority of installed local area 
networks within the next few years. 
Similarly, the three examples of operat¬ 
ing systems in Chapter 5 are CP/M, 


Pilot, and Unix. MS-DOS for the IBM 
PC is conspicuous by its absence. 

Chapter 5, “Office Systems Tools,” 
also demonstrates the strong side of the 
book’s presentation. It includes expla¬ 
nations of RasterOp (or BitBlt) usage 
and windowing systems that, while sim¬ 
ple enough for non-expert readers to 
enjoy, are in-depth enough to examine 
such issues as determining which win¬ 
dow receives the keystroke. 

Chapters 6 and 7 look at “User Inter¬ 
faces” and “Office Documents,” 
respectively. Chapter 6 provides insight 
into the attraction and pitfalls of icon- 
based object-oriented systems. 

Chapter 7 is one of the clearest expla¬ 
nations I have read of the philosophical 
differences between SGML, 
ODA/ODIF, and Interscript document 
interchange standards, and why the 
Postscript page description language 
has become so popular. 

The book’s thesis is presented in 
Chapter 8, “Office Application Sys¬ 
tems,” where the authors show how, 
based on their definitions in Chapters 6 
and 7, all office applications can be 
viewed as document processing systems. 
Spreadsheets, database systems, name 
servers, electronic mail, and conferenc¬ 
ing are developed as examples to show 
this. 

The authors comment in their preface 
on “how difficult it is to write a coher¬ 
ent book within this fuzzy, interdisci¬ 
plinary, rapidly changing field.” The 
difficulty shows in this book. While cas¬ 
ual readers can gain some insight into 
the breadth of technology behind 
today’s office automation movement, 
serious students will find it lacking in 
detail. The inconsistency in style and in 
depth of presentation makes this book 
read like a magazine. It is a lot more 
readable than a technical journal and 
even most textbooks, but the lack of an 
index seriously degrades its usefulness 
as a reference work, as do the occa¬ 
sional technical errors. 

Vincent C. Jones 

Ft. Collins, Colo. 
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The Pick Operating System: A Practical Guide 


Roger J. Bourdon (Addison-Wesley 
Publishing Co., Reading, Mass., 

1987, 450 pp., $29.95, softcover) 

This book is intended as a reference 
for experienced Pick users, and as an 
advertisement aimed at people consider¬ 
ing Pick for the first time. Since the 
book is intended for two audiences, this 
review is by two readers: a system 
administrator using a Pick-based appli¬ 
cation and a database programmer 
interested in multiuser applications. 

For a system administrator, this book 
is indeed a useful and practical guide. 


For a novice system 
administrator, this book 
is indeed a useful and 
practical guide. 


The reader starts at the very beginning 
with the basic file structure of the Pick 
system and follows through all the verbs 
detailing their options and attributes. 
While much of this is the same informa¬ 
tion found in the technical manual, it is 
much easier for a novice user to grasp 
the fundamentals as presented here. 

The author’s style is direct, and he fol¬ 
lows up with examples. 

Based on Pick on a Honeywell Level 
6, the discussions of the major ele¬ 
ments, the editor, and Pick Basic are 
error-free. There are major differences 
created by specific application pro¬ 
grams. The section on the interactive 
debugger in the Pick Basic chapter is 
especially interesting. The author 
describes the function and use of the 
debugger, lists the commands, and gives 
some examples. This information is not 
in the technical manual provided with 
the Honeywell system, and the manual 
warns that the debugger in the hands of 
a novice could seriously damage the 
stored data. This book clarifies why 
access to the system editor and debug¬ 
ger must be controlled to protect the 
system. 

For the system administrator who 
may be a computer novice, the author 
gives important guidelines on proper 
file saves to protect the database and 
describes how the system protects its 
own integrity. He also discusses the 
administrator’s role in safeguarding the 
security of the system. 

For the more experienced user, the 
book is weak on designing and imple¬ 
menting real applications. Pick has 
several levels of programming built on 


the underlying database system, but the 
interconnections between the levels are 
not very intuitive. The book includes 
chapters on four topics relevant to 
application developers: the Access data¬ 
base query language, Pick Basic, the 
procedural language (Proc), and fourth- 
generation application building systems. 

The book closes with 97 pages of 
appendixes and glossary, and an exten¬ 
sive 10-page index. Since there may be 
slight variations among systems, it is 
safer to find some of this information 
in the specific system’s technical 
manual. 

The book has some problems as a 
guide for a newcomer considering Pick. 
The biggest drawback is the organiza¬ 
tion; the book begins with a strong 
focus on the specifics of Pick, and the 
comparative strengths of the system are 
not really discussed until the final two 
chapters, which are easily overlooked as 
the reader enters the large appendixes. 
Even the first chapter is mostly a list of 
Pick features discussed in the following 
chapters. Some other operating systems 
are mentioned, but the only operating 
system compared in any detail with Pick 
is Unix. 

The chapter entitled “Pick on the 
IBM PC and Compatibles” contains 
valuable information for users who are 
considering incorporating PCs into 
their Pick-based systems. The chapter 
discusses native Pick, and much of it is 
about transferring information between 
MS-DOS and Pick partitions and con¬ 
figuring multiple serial ports. Pick 
look-alike systems under MS-DOS and 
Pick for the Apple Macintosh are not 
discussed. Also, little mention is made 
of existing Pick implementations for 
mainframes. 

The system administrator reviewer 
felt that these sections adequately 
addressed Pick’s strengths and weak¬ 
nesses. Pick has significant strengths in 
its intrinsic database organization and a 
consistent approach to storing data, 
and it has a solid track record as a 
multiuser operating system. Pick’s main 
weaknesses involve communications 
and arithmetic accuracy, and both of 
these problem areas are being 
addressed. 

However, the database programmer 
reviewer felt that the final two chapters 
in particular, and the book in general, 
failed to establish a rationale for using 
Pick. In particular, the comparative dis¬ 
cussion lacks currentness and sub¬ 
stance. It might be reasonable to accept 
the omission of the relatively new OS/2, 
though many businessmen and 
programmers are already considering— 


and using—it, but too many well- 
established alternatives are not even 
mentioned or are dismissed because 
they “addressed limited machine mar¬ 
ketplaces.” Even the comparisons made 
to Unix are quite superficial. 

For an interested but Pick-ignorant 
reader, many valuable features of Pick 
are discussed in the body of the book. 
However, there are too many details, 
links, and cross references, both for¬ 
wards and backwards, to clearly show 
“what manner of beast” this operating 
system is. Most of the tools of a power¬ 
ful multiuser database system appear to 
be available, but the book does not 
demonstrate clearly how to use the 
tools, nor how or whether these tools 
work together in an intergated fashion 
to build applications. 

In summary, this book is indeed a 
practical guide for a Pick user. It would 
be helpful for a novice system adminis¬ 
trator and would still be a worthwhile 
investment for a more experienced user 
of Pick. But if you are trying to evalu¬ 
ate the comparative merits of Pick, 
you’ll probably need to look elsewhere. 

Doug Ramming 

University of Texas, Austin 

Shannon Jacobs 

Database consultant, Austin, Texas 


Principles of Computer 
Science: Concepts, 
Algorithms, Data 
Structures, and 
Applications 

M. Sandra Carberry, A. Toni Cohen, 
and Hatem M. Khalil (Computer 
Science Press, Rockville, Md., 1986, 
636 pp., $36.95) 

The authors contend that this book is 
“a balanced introduction to the dis¬ 
cipline of computer science, giving 
attention to each component of the 
field.” It is not clear, though, why any¬ 
one should learn a discipline as large as 
computer science from a single book. 

The book is organized into five 
parts—Foundations, Systems and Lan¬ 
guages, Programming with Pascal, 
Applications, and Perspectives. The 
four chapters in the first part detail the 
notions of problem solving, algorithms, 
and complexity and verification of 
algorithms. Complexity and verifica- 
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tion, which are considered difficult for 
a beginner, are dealt with in a sketchy 
manner. Also, the references to 
“input” in the algorithms in the second 
chapter are incorrect. For instance, 
algorithm B on page 23 requires in its 
input specification “any two integers, 
each less than 1,000 in absolute value,” 
but the instructions in the algorithm 
completely ignore them. Tracing tables 
help the reader to better understand the 
algorithms. 

The first chapter in the section on 
systems and languages examines repre- 


It is not clear why 
anyone should learn a 
discipline as large as 
computer science from a 
single book. 


sentation of data in a computer. The 
next chapter uses a hypothetical 
machine language to explicate the prin¬ 
ciples of computer architecture. The 
authors present concepts of syntax, 
semantics, and pragmatics associated 
with programming languages in the sec¬ 
tion’s third chapter. It is interesting to 
note that the authors present these 
materials before the reader is exposed to 
a high-level programming language. 

The fourth chapter, on system soft¬ 
ware, traces the evolution of operating 
system components. The authors give 
an explanation of a two-pass assembler, 
but they make no mention of a macro 
assembler. Also, the authors say 
“pages” and “segments” are one and 
the same. 

“Programming With Pascal” is the 
longest section of the book, and it 
presents the material in a useful format 
for an introductory text. Consistent use 
of Backus Naur Form in the explana¬ 
tions of the various syntactic constructs 
of Pascal deserves special mention. A 
number of simple and useful examples 
enhance the section’s readability. How¬ 
ever, the presentation style often resem¬ 
bles that of a language manual. There 
are a number of typographical and tech¬ 
nical errors; for example, the data types 
“set” and “string” are missing from 
one figure and a full line of output is 
missing in the solution of a problem. 

Part four of the book presents five 
different application areas. Searching 
and sorting algorithms are presented 
first. Trace tables help the reader under¬ 
stand the algorithms. The discussion on 
file structures in the next chapter is 
fairly elaborate and well organized. 


However, the material on database 
management systems is sketchy. 
Numerical analysis and artificial intelli¬ 
gence are presented in the next two 
chapters. The section on problem solv¬ 
ing methods in artificial intelligence is 
superb. The fifth chapter in this section 
covers software engineering methods of 
testing and debugging. 

The last section begins with an exami¬ 
nation of the impact of computers on 
society, focusing on crime and privacy 
issues. The second chapter, on future 
directions, deals with networks and 
some aspects of programming language 
design. Object-oriented programming 
and functional languages are described 
in detail here. 

Every chapter has a summary section 
and exercises, but the references at the 
end of some of the chapters are inade¬ 
quate. A guide book provides chapter 
summaries, teaching suggestions, and 
materials for chapter tests. 

The book covers a number of com¬ 
puter science topics, but the treatment 
of Pascal is the only part that does jus¬ 
tice to the topic for the book’s intended 
audience. Many sections of the book 
are well written; if the care taken with 
these sections were extended to the rest 
of the material, this could have been a 
better book. 

Pani N. Chakrapani 

University of Redlands, Calif. 


Computer Organization 
and Architecture: 
Principles of Structure 
and Fundamentals 

William Stallings (MacMillan Pub¬ 
lishing Co., New York, 1987, 511 

pp., $38) 

This book is a wonderful example of 
how a clear and orderly presentation of 
information can be concise, readable, 
and enjoyable. Normally a book is 
skimmed for a review, but I found that 
it was impossible to skim this book—in 
fact, the harder I tried the more I found 
that I wanted to read every sentence. As 
a practicing computer architect, I feel 
this is the finest book of its type I have 
seen. Although it is by definition not 
exhaustive, it provides information that 
normally would only be found in 
several texts and through years of expe¬ 
rience. As a result, I strongly recom¬ 
mend this book for any computer 
engineer or computer scientist who 
needs a good introduction to computer 
architecture or a good desk reference. 


This book was written to present the 
nature and characteristics of modern- 
day computer systems. While many 
authors with similar charges spend 
hundreds of pages on case studies and 
endless comparisons, Stallings instead 
uses a “peeling the onion” approach. 
The first portion of the book provides a 
general overview of computer organiza¬ 
tion. The remainder of the book 
expands upon various sections of the 
computer organization until all aspects 
of computer architecture have been 
explored. This approach makes the text 
ideal not only for an introductory com¬ 
puter architecture course, but also as a 
reference text. Specific areas can be 
quickly pinpointed and studied. Fur¬ 
thermore, specific cases are dealt with 
for a specific purpose that is clearly 
understood. 

The book is divided into five major 
sections: 

• Prologue, which provides an intro¬ 
duction and brief history 

• The Computer System, which 
covers the global view of computer 
systems 

• The Central Processing Unit, which 
centers on the CPU and associated 
issues 

• The Control Unit, which handles 
internal CPU operations in greater 
detail 

• Epilogue, which covers advanced 
topics such as reduced instruction 
set computer architecture, multi¬ 
processing, and other advanced 
topics. 

Each section is more specific than the 
last. The Prologue contains a fascinat¬ 
ing history of computer evolution that 
alone justifies buying the book. The dis¬ 
cussion of popular bus structures such 
as SBI and Multibus (IEEE 796) also 
makes the book worthwhile. 

Along with the standard architectural 
topics, the book covers areas not 
usually dealt with, such as design of 
error-correcting codes, detailed cache 
design, operating system/architecture 
trade-offs, computer arithmetic, and 
pipelining. Serious students (in or out 
of school) will find the copious refer¬ 
ences invaluable for further study. The 
presentation of the references is two¬ 
fold: a traditional bibliography at the 
back of the volume, and a section at the 
end of each chapter specifically explain¬ 
ing the material covered in each refer¬ 
ence and its relevance to the discussion. 

However, no book is perfect. There 
are restrictions on the amount of mate¬ 
rial that a book can cover, a fact that 
makes many lesser authors provide 
brief explanations of “new and hot” 
topics. In fact, more than once I’ve 
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Digital Communications: Fundamentals and 
Applications 


been driven to distraction by a quickly 
composed single-page description of a 
new area of technology. Stallings does 
the reader a great service by avoiding 
topics that could not be reasonably 
covered, rather than making a half¬ 
hearted attempt. He does deal with 
RISC processors, but he does not deal 
with the most popular RISCs on the 
market, such as Am29000, SPARC, 
and ARM. Also, he totally ignores very 
large instruction word (VLIW) 
machines as a class, as well as the more 
controversial architectures. 


Stallings provides a 
refreshing new view of 
an old and tradition- 
filled area of computer 
technology. 


I would have liked more detailed 
coverage of some major areas of com¬ 
puter architecture, including some of 
the lesser known techniques for paral¬ 
lelism (such as scoreboarding) and some 
direct execution architectures. Histori¬ 
cally, machines of this type have 
provided direction for future develop¬ 
ment. Similarly, the operating system 
examples could have included some of 
the less worn examples to provide 
greater emphasis on certain hard¬ 
ware/software trade-offs. A discussion 
of the TurboDOS multiprocessor envi¬ 
ronment, the pseudoenvironments of 
RM/COS and Pick, or microcode- 
assisted operating systems would have 
been nice. 

Stallings uses microprocessors as 
examples from time to time, but his 
choice of chips is sometimes puzzling. 
The 8085 receives more coverage than 
the 8086, 68000, and Z8000 combined. 
The discussion of 32-bit microproces¬ 
sors ignores the more advanced 32000 
series, the 68020/68030, the Z80.000, 
the 80386, and even the Clipper. This is 
in keeping with Stallings’ philosophy of 
using examples to make a point, not 
simply to provide exposure. However, I 
feel that the choice of the example is as 
important as the point to be made. 

In all, this book is a refreshing new 
view of an old and tradition-filled area 
of computer technology. Its style and 
presentation are carefully tailored for 
readability, increasing its worth tremen¬ 
dously. Stallings has put in a large 
amount of work and it shows. 


Robert E. Cousins 
Commercial Systems 


Bernard Sklar (Prentice Hall, Engle¬ 
wood Cliffs, N.J., 1988, 776 pp., $40) 

Digital Communications is a compre¬ 
hensive treatment of digital signal 
modulation and transmission techniques. 
The intended audience is “senior-level 
undergraduates, first-year graduate stu¬ 
dents, and practicing engineers.” The 
preface refers to instructors using the 
text for a one-semester course, but most 
of the book describes a single process in 
a structured way, and too much would 
be omitted by squeezing the contents 
into one semester. The book would be 
more appropriate as a text for a one- 
year course. Also, practicing engineers 
will find Digital Communications use¬ 
ful, especially as a reference. 

The book is a much-expanded and 
updated version of “A Structured Over¬ 
view of Digital Communications” 
(IEEE Communications, Vol. 21, No. 

5, August 1983, and Vol. 21, No. 7, 
October 1983). The original tutorial 
covered digital communications, with 
special emphasis on digital satellite 
communications. This emphasis is still 
visible in Digital Communications. 
Other technologies, including earth- 
bound telephony, compact disc digital 
encoding/decoding, and local area net¬ 
working are introduced where appropri¬ 
ate. Most of the book follows the flow 
of a signal from source to destination. 
The outline of the book is straight¬ 
forward. 

Chapter 1 introduces key concepts 
used throughout the book, such as sig¬ 
nals, noise, and bandwidth. Signals 
must be available in digital form, so 
Chapter 2 discusses digitalization of 
analog signals and encoding techniques 
such as pulse code modulation. These 
digital signals then must be transformed 
into waveforms appropriate for the 
chosen channel, or path, between 
sender and receiver. Chapter 3 discusses 
modulation/demodulation techniques 
(phase shifting, amplitude phasing) that 
allow the receiver to “tell the bits 
apart.” 

The signals must be sent over the 
channel to the receiver. Chapter 4 dis¬ 
cusses the characteristics—signal noise 
and loss—of any path connecting trans¬ 
mitters and receivers, and explains how 
to construct a “system link budget,” 
determining the bandwidth, quality, 
and availability of a channel. The con¬ 
cepts introduced in this chapter are crit¬ 
ical to the practicing communications 
engineer, and carry through subsequent 
chapters. 


Encoding techniques that aid identifi¬ 
cation and verification of the signal at 
the receiving site, such as simple parity 
coding, more robust cyclic coding, and 
Hamming codes, are described in Chap¬ 
ters 5 and 6. 

Intelligent choices about modulation/ 
demodulation and channel coding tech¬ 
niques can substantially improve system 
performance, as discussed in Chapter 7. 
This chapter carries forward the con¬ 
cept of a “link budget” introduced in 
Chapter 4, and shows how the tech¬ 
niques discussed in the intervening 
chapters are used in practice. 

When the sender and receiver are 
geographically separated, the receiver 
must be able to organize bits into mul¬ 
tibit symbols (bytes, for example) or 
even into multibyte frames. The sender 
and receiver must be able to agree on 
the start and end of each transmission 
and each symbol, so synchronization 
techniques are discussed in Chapter 8. 

If each sender-receiver pair shares its 
communications channel with other 
senders and receivers, some method 
must be used to allocate the channel. 
Methods may be based on polling, 
reservation or token-rings, or even the 
cooperative anarchy of Aloha and 
Ethernet. These methods are discussed 
in Chapter 9. 

The remainder of the book examines 
special topics. Chapter 10 is a digression 
on spread-spectrum techniques, which 
are used in communications systems 
where jamming resistance is an impor¬ 
tant design goal. The idea is that the 
bandwidth used is much greater than 
the minimum required. 

Chapters 11 and 12 discuss source- 
level transformation techniques used 
for data compression (Huffman coding) 
to encryption. These topics are not 
exclusively part of digital communica¬ 
tions, but are frequently of interest to 
communications engineers. 

Throughout the book, Sklar 
introduces and explains principles in 
terms of real-world problems. Perfor¬ 
mance analysis and cost-effectiveness 
are topics that appear in most chapters. 
For this reason, I also recommend this 
book to practicing professionals, espe¬ 
cially those involved in satellite digital 
communications. 


Spencer Dawkins 
Bell-Northern Research 
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